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

Обновлено: 11 мая 2026 г. в 11:16

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

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

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

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

Sidecar Pattern

добавляет соседний контейнер, который расширяет приложение без изменения его кода.

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

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

Pod

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

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

Ambassador Pattern

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

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

  • Пул соединений к базе данных
  • Посредник для сервисной сетки, например Envoy
  • Размыкание проблемного внешнего вызова рядом с приложением
Приложение
локальный вызов
Ambassador
политика подключения
Внешняя БД
адрес, TLS, повторы

Локальный посредник скрывает детали подключения

Adapter Pattern

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

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

  • Экспорт метрик для Prometheus
  • Нормализация формата логов
  • Обёртка вокруг старого API без переписывания приложения
Старое приложение
свой формат
Adapter
нормализация
Prometheus
единые метрики

Нормализация форматов и метрик

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

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

Designing Data-Intensive Applications, 2nd Edition

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

Читать обзор

Replicated Load-Balanced Services

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

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

Sharded Services

делит данные между узлами по ключу: каждый шард отвечает только за свой диапазон или хэш-пространство.

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

  • Хэширование ключа, если данные равномерно распределены
  • Диапазоны по времени, региону или другому естественному признаку
  • Осторожность с горячими ключами, перебалансировкой и
Маршрутизатор
Шард A
A-F
Шард B
G-N
Шард C
O-Z

Scatter/Gather Pattern

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

Координатор
Узел 1
Узел 2
Узел 3
Сбор результата

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

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

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

Building Microservices

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

Читать обзор

Work Queue Systems

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

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

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

Event-Driven Batch Processing

запускает задание после появления файла, сообщения в очереди или вебхука.

Kubernetes Jobs
Событие
Триггер
Пакетное задание

Новый файл, вебхук или сообщение в очереди

Coordinated Batch Processing

связывает несколько этапов с зависимостями, повторной обработкой и явным состоянием процесса.

Извлечь
Преобразовать
Загрузить
Объединить

Обычно реализуется через : Airflow, Argo Workflows или Temporal.

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

Hands-Off Table

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

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

FaaS Decorator Pattern

добавляет вроде проверки доступа, логирования и ограничения частоты запросов.

Функция
Доступ
Логи
Лимит запросов

Функции добавляют сквозное поведение вокруг сервиса

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

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

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

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

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

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

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

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

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

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