System Design Space
Граф знанийНастройки

Обновлено: 25 июня 2026 г. в 01:55

Designing Distributed Systems (short summary)

средний

Эта книга ценна тем, что делает распределённые системы осязаемыми через небольшие составные блоки, а не через абстрактные схемы на десять сервисов.

Для реальных проектных решений глава помогает увидеть, как соседние контейнеры, локальные посредники, рассылка запроса, рабочие очереди и пакетная обработка собираются в прикладные сценарии.

Для интервью и инженерных разборов она полезна тем, что помогает показывать паттерны как средство упростить систему, не пряча за ними реальные ограничения и проблемные места архитектуры.

Практическая польза главы

Практика проектирования

Собирайте распределённые сценарии из небольших паттернов с понятными границами ответственности.

Качество решений

Проверяйте паттерны на идемпотентность, безопасные повторные попытки и наблюдаемость в сложных цепочках обработки.

Аргументация на интервью

Объясняйте решение через соседние контейнеры, локальных посредников, адаптеры, очереди и рассылку запроса.

Формулировка компромиссов

Проговаривайте, когда паттерны реально сокращают сложность, а когда скрывают системные проблемы.

Связанная книга

Kubernetes Patterns

Каталог паттернов для жизненного цикла приложения, конфигурации, заданий и операторов платформы Kubernetes.

Читать обзор

Designing Distributed Systems (Распределенные системы. Паттерны проектирования)

Авторы: Brendan Burns
Издательство: O'Reilly Media, 2018
Объём: 162 страниц

Разбор книги Brendan Burns: составные паттерны распределённых систем для Pod-композиции, репликации, шардирования, рассылки запроса, рабочих очередей и ответственности команд.

Оригинал
Перевод

Распределённую систему легко свести к коробочкам со стрелками и потерять суть. Брендан Бернс предлагает обратный ход: собрать её из готовых паттернов — и , паттерн Sidecar, паттерн Ambassador, Adapter, ,, , , пакетная обработка по событию и . Когда у блока есть имя и известная цена, спор об архитектуре идёт о компромиссах, а не о случайном наборе манифестов платформы.

Документальные фильмы

Структура книги

Single-Node Patterns

Паттерны Sidecar, Ambassador и Adapter решают одну задачу — добавить поведение, не переписывая приложение. В основе — внутри одного .

Multi-Node Patterns

Когда один узел перестаёт справляться, нагрузку растягивают на несколько: репликация, и .

Batch Patterns

, запуск обработки по событию и координация многошаговых вычислительных процессов.

Паттерны для одного узла

Логи, шифрование транспорта по протоколу защиты транспортного уровня (TLS), чтение конфигурации — всё это хочется вынести из кода приложения. Паттерны для одного узла ставят соседние контейнеры рядом с основным и держат сквозное поведение отдельно, не трогая саму бизнес-логику.

Sidecar Pattern

ставит рядом второй контейнер: он берёт на себя инфраструктурную работу, а код приложения остаётся нетронутым.

Где применяется:

  • Доставка логов через Fluentd или Filebeat
  • Синхронизация конфигурации отдельным контейнером
  • Завершение соединения по протоколу защиты транспортного уровня (TLS) рядом с приложением

Pod

Приложение
бизнес-логика
+
Sidecar
логи, TLS, конфигурация

Два контейнера живут в одном Pod, но отвечают за разные задачи.

Паттерны обслуживания на нескольких узлах

Глубокое погружение

Designing Data-Intensive Applications, 2nd Edition

DDIA о репликации, шардировании и гарантиях консистентности.

Читать обзор

Replicated Load-Balanced Services

запускает одинаковые экземпляры за . Это базовый путь к масштабированию сервисов .

Балансировка
Реплика A
Реплика B
Реплика C

Пакетные вычислительные паттерны

Связанная книга

Building Microservices

Sam Newman о координации бизнес-процессов и взаимодействии сервисов.

Читать обзор

Work Queue Systems

кладёт в очередь, а обработчики забирают их параллельно.

Где применяется:

  • Источник создаёт задачи
  • Очередь выравнивает скорость между этапами
  • Обработчики масштабируются независимо от источника
Источник
Очередь
Обработчик 1
Обработчик 2
Обработчик 3

Ответственность команд и функции как сервис

Hands-Off Table

В три часа ночи важно не гадать, кого будить. фиксирует, какая команда владеет компонентом, кто его поддерживает и к кому идти во время инцидента.

Команда A
Команда B
Шлюз API
владеет
поддерживает
Платежи
поддерживает
владеет
Озеро данных
владеет
-

Применение на интервью по системному дизайну

Полезные концепции

  • Паттерн Sidecar для
  • Паттерн Ambassador для интеграции с
  • Шардированные сервисы для роста данных и нагрузки
  • Рассылка запроса и сбор результатов (Scatter/Gather) для параллельного поиска и аналитики
  • для пакетной обработки

Где пригодится

  • Как добавить сбор логов без изменения кода приложения?
  • Как масштабировать сервис ?
  • Как реализовать ?
  • Как обработать миллионы событий без перегрузки потребителей?

Главные выводы

Паттерны для одного узла начинаются с .
Реплицированные сервисы дают самый дешёвый рост — но только пока состояние вынесено наружу.
нужно, когда один узел уже не держит объём данных или поток запросов.
Рассылка запроса и сбор результатов (Scatter/Gather) помогает ускорять .
Очередь между этапами гасит всплески нагрузки: производитель и потребители масштабируются порознь.
Хороший паттерн снижает связность, но плохой выбор добавляет новый слой операционной сложности.

Связанные главы

Где найти книгу

Чтобы отмечать прохождение, включи трекинг в Настройки