--- title: '7 System Design Concepts Explained in 10 Minutes' source: 'https://youtube.com/watch?v=Qd9tJ3H_hPE' video_id: 'Qd9tJ3H_hPE' date: 2026-09-03 duration_sec: 644 channel: 'ByteByteGo' --- # 7 System Design Concepts Explained in 10 Minutes > Source: [7 System Design Concepts Explained in 10 Minutes](https://youtube.com/watch?v=Qd9tJ3H_hPE) ## Summary This video explains seven fundamental concepts in distributed systems design: the CAP theorem, eventual consistency, load balancing, consistent hashing, circuit breakers, rate limiting, and observability. It uses real-world examples like Google Spanner, Amazon DynamoDB, and Netflix to illustrate how these concepts are applied in practice. ### Key Points - **Reliability is about handling failures** [00:15] — Reliability is not about preventing all failures, but about continuing to operate correctly when failures are inevitable. Network partitions, server crashes, and disk failures are unavoidable. - **CAP theorem: choose two of three** [00:45] — A distributed system can only provide two of three guarantees: consistency (all nodes see the same data), availability (every request gets a response), and partition tolerance (system continues despite network failures). Since partitions are inevitable, you must choose between consistency and availability during them. - **Google Spanner: consistency over availability** [01:13] — Spanner uses atomic clocks and synchronized time across global data centers to maintain linearizable transactions. During a partition, the majority partition remains available for reads and writes, while minority partitions become read-only. - **Amazon DynamoDB: availability over consistency** [01:42] — DynamoDB continues to accept writes during a partition using eventual consistency, resolving conflicts with last-write-wins based on timestamps. Users always get responses, but may see stale data. - **Eventual consistency: a powerful promise** [02:10] — If you stop making updates, all replicas will eventually converge to the same state. This allows writes to complete immediately without waiting for all replicas, improving performance and availability. Amazon's shopping cart works this way. - **Conflict resolution strategies** [02:38] — Systems use last-write-wins (simple but can lose data), conflict-free replicated data types (CRDTs) that guarantee convergence, or application-defined merge functions based on business rules. - **Load balancers: L4 vs L7** [03:19] — L4 load balancers operate at the transport layer, routing based on IP and TCP/UDP ports. They are fast but limited. L7 load balancers operate at the application layer, analyzing HTTP headers, URLs, and content for smarter routing, but are more expensive. - **Advanced load balancing techniques** [04:00] — Modern load balancers use least-connections routing, server response time weighting, and primary/secondary configurations with heartbeat protocols for high availability. - **Consistent hashing: scaling without data reshuffling** [04:41] — Traditional modular hashing requires remapping almost all data when adding a node. Consistent hashing places keys and nodes on a ring, so adding or removing a node only affects k/n keys, where k is total keys and n is nodes. - **Circuit breakers: fail fast, not slow** [06:10] — Circuit breakers monitor failure rates and have three states: closed (normal), open (requests fail immediately), and half-open (test requests allowed). Netflix pioneered this with Hystrix. Fast failures are better than slow failures that waste resources. - **Rate limiting algorithms** [07:20] — Token bucket allows bursts while maintaining average rate. Leaky bucket processes at a constant rate. Fixed window is simple but vulnerable to edge cases. Sliding window smooths out these issues. - **Distributed rate limiting** [08:17] — In distributed systems, rate limiting requires coordination across instances. Solutions include using Redis scripts with atomic counters and TTLs, and tiered limits for authenticated vs anonymous users. - **Observability: metrics, logs, traces, events** [08:45] — Modern observability focuses on four signals: metrics (time-series data), logs (structured event records), traces (end-to-end request flows), and events (significant occurrences). Statistical anomaly detection and composite alerts reduce noise. - **Start simple, measure, then scale** [09:58] — Not every system needs all these patterns. Simple web apps serving a few thousand users don't need consistent hashing or circuit breakers. Start simple, measure everything, and add complexity only when there's clear evidence of need. ### Conclusion The video emphasizes that these seven concepts are tools for making informed trade-offs in distributed systems design, rather than one-size-fits-all solutions. The key takeaway is to start simple, measure, and add complexity only when necessary. ## Transcript доступности товаров во время пиковых нагрузок в «Чёрную пятницу» ? Почему финансовые системы редко теряют транзакции, несмотря на сбои в сети? Сегодня мы рассмотрим концепции надежности и согласованности, лежащие в основе высокомасштабных распределенных систем. Давайте сразу перейдем к делу. Надежность системы заключается не в предотвращении всех сбоев. Речь идёт о том, чтобы продолжать работать правильно, когда сбои неизбежны. Сетевые разрывы неизбежны. Серверы будут выходить из строя, жесткие диски будут ломаться. Вопрос в том, как нам создать системы, которые будут корректно справляться с этими реалиями ? Это становится возможным благодаря семи ключевым концепциям. Давайте рассмотрим каждый из них. Теоремы CAP устанавливают фундаментальное ограничение. Распределенная система может одновременно обеспечить не более двух из этих трех гарантий. Последовательность. Все заметки видят одни и те же данные одновременно. Доступность. На каждый запрос, поданный в рамках процедуры, не являющейся провальной, дается ответ. Допуск на разделение. Система продолжает работать, несмотря на сбои в сети. Поскольку в распределенных системах разрывы сети неизбежны, во время таких событий вам фактически приходится выбирать между согласованностью и доступностью. Давайте посмотрим, как реальные системы принимают это решение. Google Spanner выбирает последовательность. Она использует атомные часы и синхронизированное время в глобальных центрах обработки данных для поддержания линеаризуемых транзакций. В случае разделения сети, мажоритарный раздел остается доступным как для чтения, так и для прав доступа, в то время как миноритарные разделы становятся доступными только для чтения. Компромисс заключается в том, что права на использование нот, находящихся в миноритарной части, теряются до тех пор, пока ситуация в миноритарной части не стабилизируется. Amazon Dynamo DB выбирает уровень доступности. В случае разделения сети, она продолжает принимать права доступа, используя принцип согласованности в конечном итоге, и разрешает конфликты, полагаясь на то, что последнее право доступа имеет приоритет, исходя из временных меток. Пользователь всегда получает ответы, но иногда может увидеть устаревшие данные. Ни один из подходов не является правильным или неправильным. Это зависит от ваших требований. Банковские системы, как правило, нуждаются в согласованности. В лентах социальных сетей со временем может появиться стабильность. В конечном итоге, последовательность действий сводится к простому обещанию. Если вы прекратите вносить обновления, все реплики в конечном итоге придут к одному и тому же состоянию. Это может показаться небрежным подходом, но для крупномасштабных систем это невероятно мощный инструмент . Вот почему. В системе с конечной согласованностью процесс рисования может завершиться немедленно, без ожидания подтверждения от всех реплик. Это повышает производительность и доступность. Корзина покупок Amazon работает именно так. Вы можете добавлять предметы, даже если некоторые серверы временно недоступны. Но как система обрабатывает конфликты, когда разные реплики получают разные обновления? При возникновении конфликтов системы используют различные стратегии разрешения. При определении последнего правого ветра используется временная метка для выбора наиболее актуального обновления. Просто, но может привести к потере данных. Бесконфликтные реплицируемые типы данных используют математические свойства для гарантии того, что все реплики сходятся к одному и тому же состоянию независимо от порядка обновления. Функции слияния, определяемые приложением, позволяют разработчикам создавать собственную логику для разрешения конфликтов на основе бизнес- правил. Современные системы, такие как Dynamob, обычно достигают стабильности в течение миллисекунд в нормальных условиях, благодаря чему последующая парковка практически незаметна для пользователей. Низкий баланс распределяет входящие запросы между несколькими серверами. Звучит за эффективной балансировкой нагрузки стоит сложная инженерная задача . Существует два основных типа. Балансировщики нагрузки 4-го уровня работают на транспортном уровне. Они принимают решения о маршрутизации на основе IP-адресов и портов TCP/UDP. Они работают быстро, потому что им но при этом их возможности в области маршрутизации ограничены. Балансировщики нагрузки 7-го уровня работают на прикладном уровне. Они могут анализировать HTTP-заголовки, URL-адреса и даже содержимое запросов, чтобы принимать более взвешенные решения о маршрутизации. Более затрат. Современные балансировщики нагрузки выходят за рамки простого распределения нагрузки по принципу «кругового распределения». Маршрутизация арендованных соединений направляет новые запросы на сервер, обрабатывающий наименьшее количество активных соединений. Время аренды сервера влияет на скорость ответа каждого сервера, позволяя избежать использования более медленных серверов. Для обеспечения высокой доступности сами устройства с низким балансом ресурсов развертываются в конфигурациях первичного и вторичного уровней с использованием протоколов пульсации. Если основной блок выйдет из строя, резервный блок возьмет на себя управление в течение миллисекунд. Последовательное хеширование гарантирует, что один и тот же клиент будет постоянно обращаться к одному и тому же серверу, что крайне важно для поддержания состояния сессии. В прошлом видео мы говорили о горизонтальном масштабировании. Вот проблема, с которой сталкиваются крупные системы горизонтального масштаба. У вас есть данные, распределенные по нескольким узлам, и вам нужно добавить или удалить узлы, не перемещая огромные объемы данных. Традиционные методы хеширования здесь не подходят. Если вы используете простое модульное хеширование, то добавление одного узла потребует переназначения почти всех ваших данных. Это дорого и создаст неудобства. Последовательное хеширование элегантно решает эту проблему. Вместо прямого сопоставления клавиш с нотами, и клавиши, и ноты размещаются на кольцевом хеше. Вот как это работает шаг за шагом. Сначала хешируем каждую ноту, чтобы определить ее положение на кольце. Во-вторых, чтобы определить, к какому месту относятся данные, хешируйте ключ и двигайтесь по кольцу по часовой стрелке, пока не дойдете до первой ноты. В-третьих, продублируйте данные на следующие n минус одну ноту по часовой стрелке кольца. При добавлении новой заметки она получает права собственности только на ключи своих ближайших соседей. При удалении ноты клавиши перераспределяются на следующую ноту в кольце. В результате добавления или перемещения заметок требуется переместить всего k за n клавиш, а не почти все клавиши, где k — общее количество клавиш, а n — количество узлов. И Amazon Dynamo DB, и Apache Cassandra используют согласованное хеширование именно по этой причине. Это позволяет им масштабироваться горизонтально без масштабной реорганизации данных. сбоев в зависимых службах. Автоматические выключатели предотвращают это. Автоматический выключатель отслеживает массив частоты отказов при вызовах зависимой службы. В нём три штата. Закрытые запросы обрабатываются в обычном режиме. Открытые запросы блокируются немедленно, возвращая быстрые ошибки. Приоткрыто. Пропускается несколько тестовых запросов, чтобы проверить, восстановилась ли работа сервиса . Вот как это работает шаг за шагом. Автоматические выключатели отслеживают успешные и неудачные запросы к сервису. Когда частота отказов превышает пороговое значение, автоматический выключатель переходит в разомкнутое состояние. В открытом состоянии запросы немедленно завершаются с ошибкой, даже не пытаясь обратиться к неисправной службе. Это предотвращает истощение ресурсов и дает неисправному сервису время на восстановление. По истечении заданного времени автоматический выключатель переходит в полуоткрытое положение и пропускает несколько тестовых запросов. Если тестовые запросы пройдут успешно, автоматический выключатель замкнется, и нормальная работа возобновится. Если они потерпят неудачу, его откроют снова. Компания Netflix первой применила этот подход со своей библиотекой истории, и теперь он является стандартом в микросервисных архитектурах. Главная мысль заключается в том, что быстрые отказы лучше, чем медленные отказы, которые расходуют ресурсы. Ограничение скорости запросов определяет, сколько запросов клиент может отправить в течение заданного временного интервала. Это защищает системы от перегрузки и неправильного использования. Существует несколько алгоритмов, каждый из которых обладает различными характеристиками. В хранилище токенов токены накапливаются с фиксированной скоростью до достижения максимальной вместимости. Каждый запрос расходует токен. Это позволяет контролировать импульсную скорость передачи данных, сохраняя при этом среднюю скорость. Технология Leaky Bucket обрабатывает запросы с постоянной скоростью, сглаживая пики трафика. Избыточные просьбы либо милы, либо отброшены. Запросы с фиксированным окном могут отправляться через дискретные интервалы времени. Простой, но подверженный влиянию граничных условий, когда клиенты могут удвоить скорость, запрашивая данные в промежутках между окнами. В скользящих окнах используется скользящее среднее, которое сглаживает проблемы, возникающие при использовании фиксированных окон. В распределенных системах ограничение лучей становится более сложным процессом. Нельзя просто подсчитывать количество запросов на одном сервере. Необходима координация между несколькими экземплярами. Одно из решений — ограничители космических лучей, использующие скрипт l для атомарного увеличения счетчиков и установки TTL. Это обеспечивает единообразное ограничение лучей во всем кластере сервисов. Во многих системах реализовано ограничение количества пользователей на разных уровнях с различными лимитами для аутентификаторов и анонимных пользователей, а также постепенно ужесточающимися ограничениями по мере а также постепенно ужесточающимися ограничениями по мере обнаружения подозрительных закономерностей. Вы можете управлять тем, что можете измерить. Мониторинг обеспечивает прозрачность поведения и производительности системы. Современная наблюдательность фокусируется на четырех ключевых типах сигналов. Метрики, числовые данные временных рядов, такие как загрузка ЦП, частота запросов и количество ошибок. Журналы содержат структурированные записи отдельных событий с контекстной информацией. Отслеживает сквозные потоки запросов, показывая, как один запрос перемещается по вашей распределенной системе. события, значимые происшествия, такие как развертывание или изменение конфигурации. Задача состоит в обработке огромных объемов телеметрических данных. Крупномасштабные системы телеметрических данных. Крупномасштабные системы аспекта. Вам нужно быстро выявлять реальные проблемы, но вы не хотите быть перегружены ложными тревогами. Статические пороговые значения работают для стабильных показателей, но перестают работать при изменении характера трафика. Современные системы используют статистическое обнаружение аномалий, которое выявляет нормальные закономерности и оповещает об отклонениях. Составные оповещения объединяют несколько сигналов для снижения уровня шума. Вместо того чтобы выдавать оповещения только о высокой загрузке ЦП, вы можете выдавать оповещения, когда загрузка ЦП высока, увеличивается количество ошибок и замедляется время отклика. Цель состоит в достижении целевых показателей уровня обслуживания, которые позволяют оценить пользовательский опыт. Не каждой системе нужны все эти шаблоны. Простое веб-приложение, обслуживающее несколько тысяч пользователей, не нуждается в согласованном хешировании или автоматических выключателях. Рассмотренные нами концепции предоставляют вам инструменты для осознанного принятия такого компромисса, вместо того чтобы обнаруживать ограничения вашей системы во время сбоя. Начинайте с простого, всё измеряйте и усложняйте только тогда, когда у вас есть чёткие доказательства необходимости этого. Так доказательства необходимости этого. Так создаются системы, которые надежно масштабируются. Если вам нравятся наши видео, вам может понравиться и наша рассылка по системному проектированию. В нем рассматриваются темы и тенденции в проектировании крупномасштабных систем. Нам доверяют 1 миллион system design. Trusted by 1 million readers. Subscribed at blog.by go.com.