System Design — карта тем и подготовка
Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.
System design — умение спроектировать систему под измеримые требования — сколько пользователей, какой RPS, допустимая задержка, RTO/RPO при сбое, бюджет и сроки команды. На собеседовании и в продакшене от вас ждут не перечисления технологий, а цепочку решений с trade-off.
Эта страница — навигатор по материалам "Вселенной IT": шесть опорных блоков (как на типовых cheat sheet), чеклист технологий и порядок чтения. Детали по каждому рычагу — в 12 концепциях; консенсус и лидер — в Алгоритмы выбора лидера в распределённых системах и распределённых системах.
Проверьте, что понимаете задержку и пропускную способность на уровне HTTP/TCP/DNS — § в основах сети.
Затем 12 концепций → NFR в цифрах → одна задача из классических задач design с блок-схемой от клиента до БД (для "ложного CRUD" удобна email-рассылка).
Порядок изучения — от пакета до Kubernetes
Многие начинают с оркестрации и диаграмм, не понимая, что происходит с сетевым запросом и где лежат данные. Ниже — порядок, который даёт устойчивую базу; каждый шаг опирается на предыдущий.
| Шаг | Тема | Зачем | Главы энциклопедии |
|---|---|---|---|
| 1 | Сети | Без HTTP, TCP, DNS и RTT нельзя честно говорить о latency API | Сеть и интернет — intro, TCP/UDP, HTTP, DNS, задержка и throughput, HTTP-экосистема |
| 2 | Базы данных | Масштабирование — это прежде всего данные: индексы, репликация, партиционирование; массовые загрузки — batch/chunk | Опорные темы, Основы БД, индексы и план, репликация и шардинг, пакетная работа с данными, проектирование БД |
| 3 | Кэширование | Большая доля выигрыша — запросы, которые вообще не доходят до БД | Redis (TTL, eviction), CDN, 141 §2–3 |
| 4 | Очереди и стриминг | Развязка компонентов и переживание пиков без "укладки" всех серверов | Асинхронная обработка, брокеры, RabbitMQ, Kafka, SQS в облаке |
| 5 | Балансировка нагрузки | Горизонтальное масштабирование stateless-сервисов | 141 §1, 141 §11, горизонтальное масштабирование |
| 6 | Классические задачи design | Собрать цепочку руками, а не заучить картинку | таблица ниже, email-рассылка, масштабируемость |
| 7 | Разборы инцидентов (postmortem) | Реальное обучение — чужие отказы: что сломалось и почему | Лаборатория "Разборы", инженерия устойчивости |
После шагов 1–5 осмысленно читать Kubernetes и оркестрацию — как способ деплоить уже понятный контур, а не как замену фундаменту.
Пять инженерных рычагов
Любой trade-off в распределённой системе сводится к балансу пяти величин. Их стоит называть вслух на собеседовании и в ADR.
| Рычаг | Вопрос архитектору | Пример компромисса |
|---|---|---|
| Latency | Как быстро пользователь получает ответ? | Кэш и CDN снижают p99; синхронная репликация на все узлы увеличивает задержку записи |
| Durability | Сохранятся ли данные после сбоя? | WAL и реплики; асинхронная репликация быстрее, но риск потери последних секунд |
| Throughput | Сколько операций в секунду выдержит система? | Шардинг, очереди, read-реплики; узкое место часто — одна горячая партиция |
| Availability | Работает ли сервис при падении узла? | AP в CAP для ленты; CP для платежного ядра |
| Cost | Сколько стоят железо, трафик и люди? | "Всё в Redis" дорого по RAM; cold storage дешевле, но выше latency чтения |
Связь с CAP/PACELC — распределённые системы; измеримые цели — NFR.
Типовой контур масштабируемой системы
На собеседованиях и в продакшене снова и снова встречается одна и та же скелетная схема (иногда её называют "90% scalable systems"). Компоненты и потоки данных:
- Клиент (браузер, мобильное приложение) обращается к CDN за статикой — CSS, JS, изображения — с edge-узла ближе к пользователю.
- Динамические запросы идут на балансировщик, который распределяет нагрузку и отсекает нездоровые инстансы.
- Слой приложения — stateless API (бизнес-логика): горизонтально масштабируется; сессии и состояние — во внешнем хранилище.
- Кэш (часто Redis) — горячие ключи без чтения БД на каждый запрос.
- Primary БД — источник истины для записи; read replica — для масштабирования чтения (отчёты, ленты, редиректы).
- После успешной записи в БД (или через CDC/outbox) — событие в очередь; воркеры обрабатывают тяжёлую работу (письма, аналитика, пересчёт ленты) и при необходимости снова пишут в primary.
Детали по каждому блоку — в 12 концепциях и девяти компонентах продакшн-стека MSA.
Шесть столпов и ссылки в энциклопедии
| Столп | Суть | Ключевые темы | Где углубиться |
|---|---|---|---|
| Масштабируемость | Система растёт по нагрузке и объёму данных | Балансировка, кэш, CDN, очереди, autoscaling, шардирование | 141 §1–4, 9, 12, масштабируемость, горизонтальное масштабирование |
| Надёжность | Работа при сбоях узлов и зависимостей | Репликация, failover, бэкапы, circuit breaker, retry с лимитом | ошибки и исключения, инженерия устойчивости, SLA, РСУБД — репликация |
| Сетевые протоколы | Как компоненты обмениваются данными | HTTP/HTTPS, TCP/IP, REST, gRPC, WebSocket | HTTP-экосистема, REST, GraphQL и gRPC, WebSocket |
| Хранение | Где и как лежат данные | SQL и NoSQL, индексы, партиционирование, шардирование | основы БД, NoSQL, проектирование БД |
| Безопасность | Кто вы и что вам можно | Аутентификация, авторизация, шифрование, rate limiting | аутентификация и OAuth, OAuth в API, 141 §10 — rate limit |
| Распределённость | Несколько узлов и согласованность | CAP/PACELC, консенсус, выбор лидера | Проектирование распределенных систем, Алгоритмы выбора лидера в распределённых системах, PACELC |
Чеклист технологий из практики и собеседований
Ниже — темы, которые чаще всего встречаются в system design (в духе обзоров вроде JavaRevisited cheat sheet 2025). Каждая строка ведёт в нашу главу.
| Тема | Зачем на схеме | Глава |
|---|---|---|
| Архитектура масштабируемых систем | Горизонтальное масштабирование, stateless, NFR | Масштабируемость и параллелизм в системном проектировании, Проектирование веб-разработки, веб-стек |
| Балансировка нагрузки | Распределение RPS, health-check | 141 §1 |
| Кэширование (Redis) | Снижение latency и нагрузки на БД | Redis, 141 §2 |
| Очереди (Kafka, RabbitMQ) | Асинхронность, сглаживание пиков, события | брокеры, Kafka, MSA — Kafka |
| SQL и NoSQL | Структура, транзакции, гибкая схема, горизонтальный рост | сравнение, NoSQL intro |
| Шардирование и репликация | Ёмкость и отказоустойчивость данных | 141 §9, управление РСУБД |
| REST и gRPC | Публичный API и быстрые вызовы между сервисами | REST, GraphQL и gRPC — стили API |
| WebSocket | Двусторонний канал, чаты, live-обновления | Polling, Long Polling, SSE и Webhook, практикум REST и WebSocket |
| CDN | Статика и edge ближе к пользователю | веб-серверы и CDN, 141 §3 |
| CQRS | Разные модели для записи и чтения | CQRS, MSA — CQRS |
| Event Sourcing | Журнал событий как источник истины, проекции для чтения | Event Sourcing |
| Event-driven | Слабая связность через события | Событийно-ориентированная архитектура, Проектирование распределенных систем |
| Микросервисы и монолит | Границы деплоя и команды | Архитектурные стили и их применение, модульный монолит, паттерны MSA |
| Circuit breaker | Защита при падении зависимости | 141 §7, Инженерия устойчивости |
| Leader election (Raft, Paxos) | Один координатор записи в кластере | Алгоритмы выбора лидера в распределённых системах |
| OAuth, JWT | Вход и доступ к API | Аутентификация и авторизация, Публичный API, OAuth 2.0 и webhooks |
| Rate limiting | Защита API от злоупотреблений | 141 §10 |
Стили архитектуры — когда что звучит на схеме
| Вопрос на собеседовании | Короткий ответ | Углубление |
|---|---|---|
| Монолит или микросервисы? | Сначала измеримые NFR и границы команд; микросервисы — цена сети и согласованности | Модульный монолит, Паттерны микросервисной архитектуры, Стратегии декомпозиции монолитных систем — декомпозиция |
| Синхронно или через события? | Синхронно — когда нужен немедленный ответ; события — для развязки и пиков | Проектирование API и интеграций, Outbox |
| CQRS нужен? | Когда чтение и запись сильно различаются по нагрузке и схеме | CQRS |
| Event Sourcing? | Аудит, replay, несколько read-моделей из одного лога | Event Sourcing |
| Одна БД или у каждого сервиса своя? | В MSA — database per service; согласованность через Saga и события | Паттерны микросервисной архитектуры, 2124 Saga |
Девять типовых компонентов (gateway, registry, auth, БД, кэш, брокер, метрики, логи) — в паттернах микросервисной архитектуры.
Их удобно накладывать на ответ system design после блок-схемы запроса.
Каркас ответа на system design interview
Типичные 45–60 минут делят так (названия шагов могут отличаться у интервьюера):
| Этап | Время | Что сделать |
|---|---|---|
| Уточнение требований | 5–10 мин | Функции (MVP), NFR (DAU, RPS, p99 latency, объём данных, RPO), ограничения (бюджет, регион) |
| Оценки (back-of-the-envelope) | 5 мин | QPS, объём хранилища, пропускная способность сети; порядок величин достаточен |
| High-level design | 15–20 мин | Клиент → CDN → gateway → сервисы → кэш/БД/очередь; подписать sync/async |
| Deep dive | 15–20 мин | 1–2 узких места: шардирование, кэш, консистентность, отказ узла |
| Узкие места и trade-off | 5 мин | Single point of failure, hot key, split-brain, кэш-инвалидация |
Полезные якоря из раздела:
- NFR формулировать измеримо — Проектирование под нефункциональные требования
- Оценка альтернатив — Оценка архитектурных альтернатив
- Workshop по домену — Event Storming
Классические задачи system design
Прорисуйте каждую задачу по каркасу собеседования выше: NFR → оценки → high-level → deep dive. Полный разбор URL shortener — в масштабируемости и параллелизме. Развёрнутый разбор email-канала (bounces, DMARC, state machine) — в Email-рассылка как распределённая система.
| Задача | Доминирующая нагрузка | Ключевые приёмы | Куда углубиться |
|---|---|---|---|
| Сервис коротких URL | Чтение (редирект) >> запись | Кэш по коду, KV-хранилище, шард по hash, аналитика кликов в очередь | 2.md § URL shortener, пример ниже |
| Rate limiter | Очень частые проверки лимита | Счётчик в Redis, token/leaky bucket, gateway или middleware | 141 §10, Redis — rate limiter |
| Чат | Много долгих соединений, fan-out сообщений | WebSocket/SSE, шард по room_id, очередь на доставку офлайн-пользователям | WebSocket, практикум REST и WebSocket |
| Лента (news feed / timeline) | Чтение ленты, тяжёлая запись "пост опубликован" | Fan-out on write или on read, кэш ленты, precomputed timelines в Redis | Проектирование распределенных систем — AP для ленты, CQRS, событийная архитектура |
| Система уведомлений | Всплески, много каналов (push, email, SMS) | Очередь по типу канала, идемпотентность, retry, шаблоны и предпочтения пользователя | брокеры, pub/sub в 141 §5 |
| Email-рассылка / newsletter | Всплеск при Send, медленная внешняя доставка | Outbox, worker pool, state machine, suppression, webhooks bounces, SPF/DKIM | Email-рассылка как распределённая система, пример ниже |
Пример — сервис коротких URL
Краткая демонстрация каркаса (без полного расчёта).
Требования (пример). 100M URL в месяц, чтение в 100 раз чаще записи, редирект p99 менее 100 ms, срок жизни ссылки опционален.
High-level. Клиент → балансировщик → stateless API → кэш (Redis) по short code → при промахе read replica или шард (hash кода). Запись — генерация кода, INSERT в primary, прогрев кэша. Клики — асинхронно в Kafka → агрегаты.
Deep dive. Snowflake/base62; коллизии — retry; hot URL — отдельный ключ в кэше; при partition сети — доступность редиректа с eventual учётом кликов.
Похожие разборы — Проектирование веб-разработки (веб), имитационное моделирование.
Пример — сервис email-рассылки
Краткая демонстрация каркаса (полная схема — Email-рассылка как распределённая система).
Требования (пример). 500k подписчиков, кампания "разослать за 30 минут", p99 постановки в очередь менее 2 с, дубликат письма одному адресату недопустим, hard bounce больше не получает писем.
High-level. Админка → API → запись кампании и строк campaign_recipient в primary + строки outbox в одной транзакции → relay кладёт задачи в очередь → воркеры → SES/SendGrid → webhook bounce/complaint обновляет suppression. Open/unsubscribe — отдельные лёгкие HTTP-сервисы.
Deep dive. Идемпотентный ключ (campaign_id, recipient_id); per-MX throttle; отдельная DLQ для poison messages; метрики глубины очереди и complaint rate; SPF/DKIM/DMARC до первого массового Send.
Типичный сбой. Воркер упал после accepted у ESP, до UPDATE в БД — при повторе задачи статус уже accepted, повторной отправки нет (идемпотентность).
Учёба на чужих сбоях
Postmortem — документ после инцидента — симптом, root cause, mitigation, fix, профилактика. Чтение публичных разборов (AWS, GitHub, Cloudflare, Statuspage компаний) учит видеть цепочку отказа, а не отдельную "упавшую кнопку".
| Что смотреть в разборе | Зачем |
|---|---|
| Граница системы и зависимости | Понять, какой компонент был SPOF |
| Метрики до и во время сбоя | Связать latency/RPS/error rate с действиями |
| Что сработало в mitigation | Runbook, откат, feature flag, drain очереди |
| Пункты профилактики | Часто — кэш, лимиты, тесты на отказ узла |
Шаблон и термины — лаборатория "Разборы". Связь с надёжностью — инженерия устойчивости, SLA.
Маршрут чтения по уровню
Базовый (1–2 недели) — следуйте порядку изучения сверху вниз:
- Сети — 2.03 intro, §4, HTTP
- БД — 3.05 intro, 3.08 репликация
- Кэш и CDN — Redis, 141 §2–3
- Очереди — Брокеры сообщений · 141 §4–5
- 12 концепций архитектуры распределённых систем целиком → одна классическая задача
- Аутентификация
Продвинутый
- Проектирование распределенных систем · Алгоритмы выбора лидера в распределённых системах
- Паттерны микросервисной архитектуры · Инженерия устойчивости
- Микросервисы — intro · Kubernetes
- Итоги · чек-лист · разборы инцидентов
Внешние ресурсы
- System Design Interview Cheat Sheet (2025) — обзор тем, книг и курсов (англ.)
- Классика: Designing Data-Intensive Applications (Kleppmann) — хранение и распределённость; System Design Interview (Xu) — формат собеседований
В энциклопедии те же идеи разложены по главам с привязкой к стеку проекта и соседним разделам (сеть, БД, DevOps, ИБ).