System Design — карта тем и подготовка
System design — умение спроектировать систему под измеримые требования: сколько пользователей, какой RPS, допустимая задержка, RTO/RPO при сбое, бюджет и сроки команды. На собеседовании и в продакшене от вас ждут не перечисления технологий, а цепочку решений с trade-off.
Эта страница — навигатор по материалам «Вселенной IT»: шесть опорных блоков (как на типовых cheat sheet), чеклист технологий и порядок чтения. Детали по каждому рычагу — в 12 концепциях; консенсус и лидер — в 142.md и распределённых системах.
Проверьте, что понимаете задержку и пропускную способность на уровне HTTP/TCP/DNS — § в основах сети. Затем 12 концепций → NFR в цифрах → одна задача из классических задач design с блок-схемой от клиента до БД (для «ложного CRUD» удобна email-рассылка).
Порядок изучения — от пакета до Kubernetes
Многие начинают с оркестрации и диаграмм, не понимая, что происходит с сетевым запросом и где лежат данные. Ниже — порядок, который даёт устойчивую базу; каждый шаг опирается на предыдущий.
| Шаг | Тема | Зачем | Главы энциклопедии |
|---|---|---|---|
| 1 | Сети | Без HTTP, TCP, DNS и RTT нельзя честно говорить о latency API | Сеть и интернет — intro, TCP/UDP, HTTP, DNS, задержка и throughput, HTTP-экосистема |
| 2 | Базы данных | Масштабирование — это прежде всего данные: индексы, репликация, партиционирование | Опорные темы, Основы БД, индексы и план, репликация и шардинг |
| 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, консенсус, выбор лидера | design/21.md, 142.md, PACELC |
Чеклист технологий из практики и собеседований
Ниже — темы, которые чаще всего встречаются в system design (в духе обзоров вроде JavaRevisited cheat sheet 2025). Каждая строка ведёт в нашу главу.
| Тема | Зачем на схеме | Глава |
|---|---|---|
| Архитектура масштабируемых систем | Горизонтальное масштабирование, stateless, NFR | 2.md, design/119.md, веб-стек |
| Балансировка нагрузки | Распределение RPS, health-check | 141 §1 |
| Кэширование (Redis) | Снижение latency и нагрузки на БД | Redis, 141 §2 |
| Очереди (Kafka, RabbitMQ) | Асинхронность, сглаживание пиков, события | брокеры, Kafka, MSA — Kafka |
| SQL и NoSQL | Структура, транзакции, гибкая схема, горизонтальный рост | сравнение, NoSQL intro |
| Шардирование и репликация | Ёмкость и отказоустойчивость данных | 141 §9, управление РСУБД |
| REST и gRPC | Публичный API и быстрые вызовы между сервисами | 130 |
| WebSocket | Двусторонний канал, чаты, live-обновления | 129, практикум REST и WebSocket |
| CDN | Статика и edge ближе к пользователю | веб-серверы и CDN, 141 §3 |
| CQRS | Разные модели для записи и чтения | 2122.md, MSA — CQRS |
| Event Sourcing | Журнал событий как источник истины, проекции для чтения | 2123.md |
| Event-driven | Слабая связность через события | 2127.md, design/21.md |
| Микросервисы и монолит | Границы деплоя и команды | 101.md, модульный монолит, паттерны MSA |
| Circuit breaker | Защита при падении зависимости | 141 §7, 2136.md |
| Leader election (Raft, Paxos) | Один координатор записи в кластере | 142.md |
| OAuth, JWT | Вход и доступ к API | 111, 1171.md |
| Rate limiting | Защита API от злоупотреблений | 141 §10 |
Стили архитектуры — когда что звучит на схеме
| Вопрос на собеседовании | Короткий ответ | Углубление |
|---|---|---|
| Монолит или микросервисы? | Сначала измеримые NFR и границы команд; микросервисы — цена сети и согласованности | 2126, 118, 104 — декомпозиция |
| Синхронно или через события? | Синхронно — когда нужен немедленный ответ; события — для развязки и пиков | 117, Outbox |
| CQRS нужен? | Когда чтение и запись сильно различаются по нагрузке и схеме | 2122 |
| Event Sourcing? | Аудит, replay, несколько read-моделей из одного лога | 2123 |
| Одна БД или у каждого сервиса своя? | В MSA — database per service; согласованность через Saga и события | 118, 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 формулировать измеримо — design/1116.md
- Оценка альтернатив — design/2141.md
- Workshop по домену — Event Storming
Классические задачи system design
Прорисуйте каждую задачу по каркасу собеседования выше: NFR → оценки → high-level → deep dive. Полный разбор URL shortener — в масштабируемости и параллелизме. Развёрнутый разбор email-канала (bounces, DMARC, state machine) — в 144.md.
| Задача | Доминирующая нагрузка | Ключевые приёмы | Куда углубиться |
|---|---|---|---|
| Сервис коротких 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 | design/21.md — AP для ленты, CQRS, событийная архитектура |
| Система уведомлений | Всплески, много каналов (push, email, SMS) | Очередь по типу канала, идемпотентность, retry, шаблоны и предпочтения пользователя | брокеры, pub/sub в 141 §5 |
| Email-рассылка / newsletter | Всплеск при Send, медленная внешняя доставка | Outbox, worker pool, state machine, suppression, webhooks bounces, SPF/DKIM | 144.md, пример ниже |
Пример — сервис коротких 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 учётом кликов.
Похожие разборы — design/119.md (веб), имитационное моделирование.
Пример — сервис email-рассылки
Краткая демонстрация каркаса (полная схема — 144.md).
Требования (пример). 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
- Очереди — 121 · 141 §4–5
- 141.md целиком → одна классическая задача
- Аутентификация
Продвинутый
- design/21.md · 142.md
- design/118.md · 2136.md
- Микросервисы — intro · Kubernetes
- Итоги · чек-лист · разборы инцидентов
Внешние ресурсы
- System Design Interview Cheat Sheet (2025) — обзор тем, книг и курсов (англ.)
- Классика: Designing Data-Intensive Applications (Kleppmann) — хранение и распределённость; System Design Interview (Xu) — формат собеседований
В энциклопедии те же идеи разложены по главам с привязкой к стеку проекта и соседним разделам (сеть, БД, DevOps, ИБ).
См. также
См. также
Другие статьи этого же раздела в боковом меню (как на странице "О разделе"). 52 элемента 33 элемента Обычно проектирование применяется к каким-то планам, схемам, моделям или расчётам, которые описывают будущий объект, включая характеристики, функции, инженерные решения. Архитектурные решения, касающиеся распределения компонентов и организации их взаимодействия, определяют фундаментальные свойства системы: её масштабируемость, отказоустойчивость, сложность. Это достигается через инверсию зависимостей — принцип, согласно которому высокоуровневые модули не должны зависеть от низкоуровневых; оба должны зависеть от абстракций. Компонентно-ориентированная архитектура - согласованность версий общих модулей и управление зависимостями между сервисами. Как резать монолит без "большого взрыва": пять вопросов перед стартом, анализ, Strangler, DDD-контексты, данные, саги и метрики успеха. Инфраструктура — это множество решений, инкапсулированных в сервисы, каждое из которых накладывает ограничения и открывает возможности. Классификация типов классов в ООП - семантика имён, роли объектов и разделение ответственности в проекте. Построение систем на классах и объектах - модель предметной области, границы ответственности и связи между сущностями. Доменная модель - как отразить предметную область в ПО, выделить сущности и зафиксировать правила бизнес-логики. Тактические строительные блоки Domain-Driven Design: Entity, Value Object, Aggregate Root, доменные сервисы, репозитории, фабрики и события — какие классы в каком слое и чем они отличаются от DTO и контроллеров.Проектирование
Паттерны проектирования
Основы проектирования и архитектуры программного обеспечения
Архитектурные стили и их применение
Стили внутренней организации кода
Принципы компонентно-ориентированной архитектуры
Стратегии декомпозиции монолитных систем
Влияние инфраструктуры на архитектурные решения
Классификация типов классов в объектно-ориентированном проектировании
Построение систем на основе классов и объектов
Доменная модель
Типы классов в DDD