System Design — карта тем и подготовка
Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.
System design представляет собой междисциплинарную инженерную дисциплину, которая охватывает процесс определения архитектуры, компонентов, модулей, интерфейсов и данных для сложной программной системы с целью удовлетворения как функциональных, так и нефункциональных требований, при этом она включает в себя принятие решений о выборе технологического стека, способах интеграции между сервисами, моделях развертывания, стратегиях масштабирования и обеспечения отказоустойчивости, и этот процесс требует глубокого понимания бизнес-контекста, анализа ограничений существующей инфраструктуры, прогнозирования будущих нагрузок и тщательного балансирования между противоречивыми требованиями, такими как производительность, надежность, стоимость и скорость разработки, причём результатом 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 представляет собой фундаментальную концепцию в системном проектировании, которая описывает неизбежный компромисс между противоречивыми качествами системы, когда улучшение одного параметра неминуемо ведёт к ухудшению другого, и классическими примерами таких компромиссов являются выбор между согласованностью и доступностью в распределённых системах, между производительностью и надёжностью при выборе механизмов репликации, между задержкой и пропускной способностью при настройке сетевого взаимодействия, между простотой разработки и масштабируемостью при выборе архитектурного стиля, а также между функциональной полнотой и скоростью работы при проектировании API, и осознанное управление trade-off требует от инженера не только технической компетенции, но и понимания бизнес-приоритетов, поскольку правильный выбор компромисса всегда зависит от конкретного контекста использования системы и её критических сценариев, и этот выбор должен быть явным, документированным и периодически пересматриваемым.
Любой trade-off в распределённой системе сводится к балансу пяти величин. Их стоит называть вслух на собеседовании и в ADR.
| Рычаг | Вопрос архитектору | Пример компромисса |
|---|---|---|
| Latency | Как быстро пользователь получает ответ? | Кэш и CDN снижают p99; синхронная репликация на все узлы увеличивает задержку записи |
| Durability | Сохранятся ли данные после сбоя? | WAL и реплики; асинхронная репликация быстрее, но риск потери последних секунд |
| Throughput | Сколько операций в секунду выдержит система? | Шардинг, очереди, read-реплики; узкое место часто — одна горячая партиция |
| Availability | Работает ли сервис при падении узла? | AP в CAP для ленты; CP для платежного ядра |
| Cost | Сколько стоят железо, трафик и люди? | "Всё в Redis" дорого по RAM; cold storage дешевле, но выше latency чтения |
Latency представляет собой показатель времени, которое проходит от момента инициирования запроса клиентом до момента получения первого байта ответа от сервера, и эта метрика измеряется в единицах времени, таких как миллисекунды или секунды, и является критически важной характеристикой производительности системы, поскольку напрямую влияет на восприятие пользователем скорости работы приложения, и в распределённых системах латентность складывается из множества компонентов, включая время передачи данных по сети, задержки на уровне сетевых устройств, время обработки запроса на сервере, время доступа к диску или памяти, а также накладные расходы на сериализацию и десериализацию данных, причём латентность имеет вероятностную природу и описывается распределением, где важны не только средние значения, но и процентили, особенно 99-й и 99.9-й, поскольку именно редкие пиковые задержки часто определяют негативный пользовательский опыт при масштабных нагрузках.
Durability представляет собой свойство системы, гарантирующее, что после успешного подтверждения операции записи данные будут сохранены постоянно и переживут любые возможные сбои, включая отключение питания, аппаратные ошибки, сбои операционной системы или аварийные остановки программного обеспечения, и в контексте баз данных и систем хранения эта гарантия достигается через механизмы журналирования упреждающей записи, репликации данных на несколько физических носителей, использование энергонезависимой памяти и периодическое создание контрольных точек, причём уровень устойчивости данных напрямую зависит от настроек синхронности записи, когда синхронная запись на диск обеспечивает максимальную надёжность, но снижает производительность, тогда как асинхронная запись повышает пропускную способность, но создаёт риск потери данных в определённых сценариях сбоя, и выбор между этими режимами является классическим примером trade-off между производительностью и надёжностью.
Throughput представляет собой меру количества операций, запросов или единиц данных, которые система способна обработать за определённый промежуток времени, обычно выражаемую в запросах в секунду, транзакциях в секунду или мегабитах в секунду, и этот показатель характеризует пропускную способность системы, то есть её способность справляться с нагрузкой, причём критически важно понимать, что throughput не является константой, а зависит от множества факторов, включая характер рабочей нагрузки, конфигурацию аппаратного обеспечения, уровень параллелизма, эффективность алгоритмов и сетевые условия, и в распределённых системах увеличение throughput обычно достигается за счёт горизонтального масштабирования, когда добавление новых узлов позволяет линейно или почти линейно наращивать общую пропускную способность, однако на практике существуют ограничения, связанные с накладными расходами на координацию между узлами, и достижение высокого throughput часто вступает в противоречие с требованиями низкой латентности и высокой согласованности.
Availability представляет собой свойство системы оставаться работоспособной и доступной для выполнения запросов пользователей в течение определённого процента времени, обычно измеряемое в терминах "девяток", где 99.9% соответствует примерно восьми часам простоя в год, а 99.99% — менее чем часу простоя в год, и это свойство достигается за счёт избыточности компонентов на всех уровнях, использования кластеризации, автоматического переключения при отказах, географического распределения и грамотного проектирования механизмов обработки сбоев, причём высокая доступность требует не только технических решений, но и организационных практик, включая мониторинг, автоматическое восстановление, безостановочные обновления и процедуры аварийного реагирования, и важно отметить, что обеспечение высокой доступности всегда связано с дополнительными затратами на инфраструктуру и усложнением системы, поэтому уровень доступности выбирается исходя из бизнес-требований и критичности системы для деятельности организации.
Cost в контексте системного проектирования представляет собой совокупность всех ресурсных затрат, связанных с созданием и эксплуатацией системы на протяжении её жизненного цикла, и эти затраты многомерны: они включают прямые финансовые расходы на аренду облачных ресурсов, закупку оборудования, оплату лицензий на программное обеспечение и зарплаты инженеров, а также операционные издержки на электроэнергию, охлаждение, сетевое подключение и поддержку инфраструктуры, но помимо явных денежных затрат, существует также стоимость в терминах сложности разработки и сопровождения, когда выбор более сложного, но дешёвого в эксплуатации решения может оказаться дороже из-за необходимости привлекать высококвалифицированных специалистов и тратить больше времени на отладку и развитие, и управление стоимостью является одной из ключевых задач архитектора, поскольку решения по масштабированию, выбору технологий и проектированию отказоустойчивости должны приниматься с учётом экономической эффективности и прогнозируемого роста нагрузки.
CAP представляет собой фундаментальную теорему распределённых систем, сформулированную Эриком Брюером и доказанную Сетом Гилбертом и Нэнси Линч, которая утверждает, что в любой распределённой системе с репликацией данных возможно гарантировать одновременно только два из трёх свойств: согласованность, означающую, что все узлы системы в каждый момент времени видят одни и те же данные, доступность, означающую, что любой запрос к системе получает корректный ответ, даже если часть узлов отказала, и устойчивость к разделению, означающую способность системы продолжать работу при потере связности между некоторыми узлами сети, и теорема демонстрирует, что при возникновении сетевого разделения система вынуждена выбирать между согласованностью и доступностью, и этот выбор определяет поведение системы в аварийных ситуациях, причём важно понимать, что CAP-теорема говорит о поведении системы во время разделения, а не в нормальном режиме работы, и на практике системы часто предоставляют компромиссные модели, такие как eventual consistency, в зависимости от требований конкретного приложения.
PACELC представляет собой расширение CAP-теоремы, которое вводит дополнительное измерение, рассматривая поведение системы не только во время сетевого разделения, но и в нормальном режиме работы, и эта аббревиатура расшифровывается как "в случае разделения выбор между доступностью и согласованностью, в противном случае выбор между задержкой и согласованностью", и суть этой теоремы заключается в том, что даже при отсутствии сетевых проблем система всё равно стоит перед фундаментальным компромиссом: если она поддерживает строгую согласованность, это требует синхронных операций, увеличивающих задержку ответа, тогда как если система оптимизирует задержку за счёт асинхронной репликации и ослабленных гарантий согласованности, она может обеспечить более быстрый отклик, и PACELC даёт более полную картину для проектирования распределённых баз данных, помогая выбрать подходящую модель согласованности в зависимости от требований приложения к скорости и точности данных.
Связь с CAP/PACELC — распределённые системы; измеримые цели — NFR.
Типовой контур масштабируемой системы
На собеседованиях и в продакшене снова и снова встречается одна и та же скелетная схема (иногда её называют "90% scalable systems"). Компоненты и потоки данных:
- Клиент (браузер, мобильное приложение) обращается к CDN за статикой — CSS, JS, изображения — с edge-узла ближе к пользователю.
- Динамические запросы идут на балансировщик, который распределяет нагрузку и отсекает нездоровые инстансы.
- Слой приложения — stateless API (бизнес-логика): горизонтально масштабируется; сессии и состояние — во внешнем хранилище.
- Кэш (часто Redis) — горячие ключи без чтения БД на каждый запрос.
- Primary БД — источник истины для записи; read replica — для масштабирования чтения (отчёты, ленты, редиректы).
- После успешной записи в БД (или через CDC/outbox) — событие в очередь; воркеры обрабатывают тяжёлую работу (письма, аналитика, пересчёт ленты) и при необходимости снова пишут в primary.
CDN представляет собой географически распределённую сеть серверов, стратегически размещённых в различных точках мира для обеспечения быстрой и надёжной доставки статического и динамического контента конечным пользователям, и основная идея заключается в кэшировании копий веб-страниц, изображений, видео, CSS-файлов, JavaScript-библиотек и других ресурсов на серверах, расположенных физически ближе к пользователям, что значительно сокращает расстояние, которое должны преодолевать данные, и тем самым снижает латентность и нагрузку на исходный сервер, причём CDN также предоставляет возможности для защиты от DDoS-атак, балансировки нагрузки, оптимизации протоколов передачи и управления трафиком, и использование CDN становится критически важным для глобальных сервисов с аудиторией из разных регионов, поскольку позволяет обеспечить стабильное качество обслуживания независимо от географического положения пользователя.
Кэш представляет собой высокоскоростное хранилище данных, которое содержит копии часто запрашиваемой информации, чтобы последующие запросы к этим данным могли быть обслужены быстрее, чем при обращении к основному источнику данных, и кэширование является одной из наиболее эффективных техник оптимизации производительности систем, поскольку позволяет значительно снизить латентность, уменьшить нагрузку на базы данных и внешние сервисы, а также сократить сетевой трафик, причём кэши реализуются на различных уровнях архитектуры: в браузерах пользователей, на CDN, на обратных прокси-серверах, в оперативной памяти приложений с использованием таких решений, как Redis или Memcached, и внутри самих баз данных, но вместе с тем использование кэша вносит сложности, связанные с управлением актуальностью данных, выбором стратегии инвалидации, решением проблемы простоя кэша и обработкой ситуаций, когда множество запросов одновременно пытаются обновить или заполнить кэш.
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
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, кэш-инвалидация |
Back-of-the-envelope представляет собой метод грубой приближённой оценки, выполняемой на основе упрощённых расчётов и разумных предположений, который используется на ранних стадиях проектирования для быстрого определения осуществимости и масштаба системы, а также для сравнения различных архитектурных альтернатив без необходимости проведения точных измерений или детального моделирования, и этот подход включает в себя оценку таких величин, как ожидаемое количество запросов в секунду, объём хранимых данных, пиковая пропускная способность сети, необходимое количество серверов и стоимость инфраструктуры, причём расчёты часто выполняются с использованием степеней десятки и общеизвестных ориентиров, например, что одна база данных способна обрабатывать несколько тысяч запросов в секунду, а одна машина может содержать определённое количество терабайт данных, и несмотря на свою приблизительность, back-of-the-envelope оценка является важнейшим навыком системного архитектора, позволяющим отсеивать нереалистичные решения до того, как в них будут вложены значительные ресурсы, и задавать правильные количественные ориентиры для дальнейшего проектирования.
Полезные якоря из раздела:
- 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, ИБ).