title: System Design Interview за 15 минут — обзорная статья по всем 12 разделам брифа source: подготовлено 2026-09-18, TASK-45.40; каркас — brief.md (12 разделов знаний); термины сверены с knowledge-base.md, methodology.md, classic-designs.md

System Design Interview за 15 минут: вся карта подготовки

Обзорная статья верхнего уровня: все 12 разделов брифа (../brief.md) в одном кадре. Задача — задать общий словарь и структуру для всей серии учебных статей articles/01…12: дальше каждая статья раскрывает свой раздел, а здесь видно, как разделы стыкуются. Формат обзора: один смысловой блок на раздел — суть, ключевые слова, что про него спросят. Глубина живёт не здесь: числа и паттерны — ../knowledge-base.md (далее KB), как вести секцию — ../methodology.md, сквозные разборы — ../classic-designs.md.

Контекст нашей секции (Yandex Codenv, этап 2): ~60 минут, спроектировать крупноблочную схему сервиса уровня «инстаграм/твиттер» и объяснить отказоустойчивость. Отсюда главное следствие: знание терминов не сдаётся отдельно — сдаётся связный рассказ с числами и трейдоффами, который ведём мы сами. Интервьюер играет вторую скрипку: молчать и ждать вопросов нельзя.

Каркас: 6 этапов секции

Все 12 разделов «прикладываются» к одному процессу — 6 этапам с таймингом (методичка §1–2):

Два правила каркаса: если не успеваем — режем детали, но эксплуатацию не режем никогда (отказоустойчивость — заявленный фокус секции); выбило из колеи — мысленно возвращаемся к цепочке «требования → API → схема → детали → числа → эксплуатация».

Как разделы брифа ложатся на этапы: 01 — сам каркас; 02 — числа на этапах 1 и 5; 03–07 — строительные блоки этапов 3–4; 08–09 — гарантии этапов 4 и 6; 10 — прикладной слой этапов 2 и 4; 11 — сквозная сборка всех этапов; 12 — этап 6. Ниже — по разделу на блок.

Разделы брифа в одном кадре

01. Фреймворк прохождения интервью и работа с требованиями

Раздел о том, как вести секцию от старта до финиша: уточнить функциональные и нефункциональные требования, договориться о масштабе (DAU, RPS чтение/запись, latency-SLO p95, доступность, консистентность, retention), зафиксировать на доске и не стирать до конца — в финале возвращаемся к листу и показываем, чем каждое требование закрыто. Сюда же минус-объём («аналитику и админку отмечаем, но не детализируем») и привычка называть трейдофф у каждого решения. Нехватка данных — норма: выдвигаем обоснованные гипотезы вслух.

• Ключевые слова: 6 этапов с таймингом, функциональные/нефункциональные требования, DAU/MAU, latency-SLO (p95/p99), минус-объём, трейдофф, контрольные точки вслух.
• Спросят: не «вопрос по разделу», а проверят поведением — ведёте ли вы секцию сами или ждёте. Умею, если: перечисляю 6 этапов с таймингом и знаю, что говорить на каждом (методичка §1–2).

02. Оценки: back-of-envelope, числа, латентность

Арифметика, на которой сходится любой дизайн: DAU → QPS avg/peak (пик ×2–3), storage = записи × размер × retention × фактор репликации, bandwidth = QPS × размер объекта, память кэша по правилу 80/20 (горячие 20 %). Вторая половина — порядки латентностей: RAM ~100 нс, random read SSD ~150 мкс, round-trip внутри ДЦ 0.5 мс, океан ~150 мс; «полоса дешевеет, латентность — нет». Правило подачи: допущение → формула → число → вывод; интервью про порядок, а не точность — округлять и подписывать единицы.

• Ключевые слова: back-of-envelope, QPS avg/peak, storage с retention, bandwidth, 80/20, latency numbers, степени двойки, «допущение → формула → число → вывод».
• Спросят: «сколько это весит за 5 лет?», «какой RPS в пике?», «влезает в одну ноду?». Умею, если: по любому сервису за 2 минуты называю RPS, объём хранения на 5 лет и ширину канала (KB §1–2).

03. Масштабирование с нуля: LB, CDN, stateless

Путь «один сервер → миллионы пользователей» как последовательность осознанных шагов: сначала вертикальное масштабирование (железо), потом горизонтальное — балансировщик перед несколькими нодами, отделение стейта от кода (stateless-сервисы + сессии в KV/кэше), отделение web-сервера от app-сервера, CDN для статики и медиа, реплики на чтение — и только потом шарды. Умение раздела — не список слов, а порядок и мотивировка каждого шага ростом нагрузки.

• Ключевые слова: vertical vs horizontal scaling, load balancer (алгоритмы, L4/L7), CDN, stateless, offload сессий, web vs app server, «лестница масштабирования».
• Спросят: «вот у вас один сервер и 10 пользователей — что добавляете при росте и в каком порядке, почему?». Умею, если: объясняю, что и в каком порядке добавляю при росте нагрузки и почему (KB §3, Сюй гл. 1).

04. Модели данных и выбор хранилища

Выбор хранилища по критериям и access pattern, а не по названию: реляционная СУБД (деньги, связи, источник правды), key-value (hot path по ключу, сессии), документная (вариативный контент), колоночная (аналитика, логи), поиск (инвертированный индекс), time-series (метрики), граф (соцграф), объектное хранилище (медиа), event log (Kafka). Базовое правило: источник правды один (RDBMS), остальные — производные проекции с известным лагом. Плюс устройство движков: B-tree (предсказуемое чтение, WAL) vs LSM (высокий write throughput, SSTable, компактация, латентность-спайки).

• Ключевые слова: SQL vs NoSQL, классы хранилищ, access pattern, источник правды, B-tree vs LSM, индексы.
• Спросят: «какая БД и почему?», «а как внутри вашей БД?». Умею, если: для любого кейса называю класс хранилища + 2 аргумента за и 1 против (KB §3, DDIA гл. 3–4).

05. Репликация и шардирование

Два способа размножить данные. Репликация: leader–follower (sync/async/semi-sync), replication lag и что он ломает (read-your-writes — читать с лидера или по позиции в логе), multi-leader (конфликты — избегаем), leaderless с кворумами W+R>N (tunable consistency, hinted handoff), failover: детект, выборы, fencing, split brain. Шардирование — последняя ступень лестницы «индексы → вертикаль → реплики → кэш → шарды»: стратегии range/hash/consistent hashing с виртуальными нодами, hot partition (селебрити), выбор ключа по access pattern, ребалансировка без даунтайма.

• Ключевые слова: leader–follower, replication lag, кворум W+R>N, failover, fencing, consistent hashing, virtual nodes, hot partition, ребалансировка.
• Спросят: «обоснуйте схему репликации и ключ шардирования для ленты/чата», «что происходит при отказе ноды?». Умею, если: обосновываю схему и поведение при отказе (KB §5–6, DDIA гл. 6–7).

06. Кэширование

Где между клиентом и БД лежит копия данных и как она не врёт. Уровни: клиент → CDN → приложение → БД. Стратегии: cache-aside (базовая), read-through/write-through, write-behind (быстро, риск потери — проговаривать). Инвалидация: TTL как страховка, delete-по-записи, версионированные ключи, событийная через шину. Отдельная катастрофа — cache stampede (thundering herd): single-flight, разогрев, jitter TTL. Ключевые метрики: hit ratio 90 %+ для hot path, eviction (LRU дефолт, LFU для неравномерных), hot key → локальный L1 + реплики ключа.

• Ключевые слова: cache-aside, write-through/write-back, TTL, инвалидация, stampede/thundering herd, LRU/LFU, hit ratio, CDN.
• Спросят: «где ставите кэш, как инвалидируете, что будет при его отказе?». Умею, если: отвечаю на все три части без паузы (KB §4).

07. Асинхронная обработка: очереди и потоки

Всё, что не нужно для ответа пользователю, — выносим из request-path в очередь: развязка сервисов, буферизация пиков (load leveling), ретраи, реплей. Словарь Kafka: topic, партиции (порядок и параллелизм), consumer group, offsets, retention. Семантики доставки: at-most-once / at-least-once / effectively-once — и главное: exactly-once между системами не существует, потребитель обязан быть идемпотентным (дедуп по ключу, таблица обработанных). Плюс: backpressure, DLQ для ядовитых сообщений, CDC и event sourcing — на уровне «чем отличаются».

• Ключевые слова: message queue, pub/sub, партиции, consumer group, at-least-once, идемпотентность, backpressure, DLQ, CDC.
• Спросят: «что выносите в очередь?», «что делаете при потере/дубле сообщения?». Умею, если: отвечаю без раздумий (KB §8, DDIA гл. 11–13).

08. Отказоустойчивость и надёжность

Заявленный фокус нашей секции. Метод: для нарисованной схемы пройти по каждой ноде и сказать, что будет при её падении — «узел → отказ → что происходит → что видно в метриках». Инструменты: SPOF-анализ, N+1 на каждом ярусе, таймаут на каждый внешний вызов, ретраи с экспоненциальным backoff + jitter (только идемпотентные), circuit breaker (closed → open → half-open), bulkhead, rate limiting (token/leaky bucket, 429 + Retry-After), load shedding, graceful degradation («отдаём кэш, отключаем статику»). Арифметика: 99.9 % = 8.7 ч/год; топология 2–4 ДЦ, majority-коммит, active–active vs active–passive.

• Ключевые слова: SPOF, N+1, failover, таймауты, backoff + jitter, circuit breaker, bulkhead, rate limiting, load shedding, graceful degradation, SLA/девятки, мульти-ДЦ.
• Спросят: «что будет, если упадёт балансировщик / нода data plane / primary БД / очередь?» — по каждой ноде схемы. Умею, если: прохожу схему целиком без затыков (KB §9, DDIA гл. 9).

09. Согласованность и распределённые транзакции

Язык, на котором договариваемся о гарантиях данных. CAP (при разделении выбираем C или A) и честнее — PACELC (даже без разделения платим латентностью за согласованность). Модели: linearizability → sequential → causal → eventual; сессионные гарантии (read-your-writes, monotonic reads) обеспечиваем отдельно. Распределённые транзакции: 2PC — точка блокировки, на секции избегаем → сага (компенсирующие действия) + transactional outbox. Кворумы дают свежесть, но не linearizability; консенсус (Raft, ZooKeeper/etcd, fencing tokens) — уметь назвать, зачем он. Уровни изоляции и гонки (lost update, write skew) — когда интервьюер углубляется в БД.

• Ключевые слова: CAP/PACELC, linearizability vs eventual, read-your-writes, 2PC vs сага, outbox, идемпотентность, Raft/консенсус, уровни изоляции.
• Спросят: «какую согласованность выбираете здесь и чем платите?». Умею, если: для конкретного кейса называю выбор и цену (KB §7, DDIA гл. 8, 10).

10. Прикладные компоненты и паттерны

Готовые блоки, из которых собираются ответы на типовые вопросы этапов 2 и 4: дизайн API (REST/gRPC, пагинация курсором, идемпотентность записей), rate limiter (token bucket / leaky bucket, распределённый — Redis + Lua), генераторы ID (snowflake: время + машина + последовательность — без единой точки координации), real-time доставка (WebSocket vs long-polling vs SSE — по направленности и совместимости), поисковый краулер (frontier, очередь, дедуп), typeahead (префиксное дерево + топ-K). Знать каждый на уровне «схема в двух фразах + трейдофф».

• Ключевые слова: REST/gRPC, курсорная пагинация, rate limiter, token/leaky bucket, snowflake ID, WebSocket/long-polling/SSE, trie/typeahead.
• Спросят: «как ограничите абуз?», «как доставите событие клиенту в реальном времени?», «как сгенерите ID без координации?». Умею, если: любой компонент — 2 фразы и трейдофф (KB §13–14, Сюй гл. 4–13).

11. Эталонные архитектуры сервисов

Разделы 01–10 дают словарь; здесь он собирается в целые решения. Четыре сквозных разбора по 6 этапам: URL shortener (эталон Яндекса: чтение доминирует → KV-зеркало + кэш), лента новостей (главный вопрос — fan-out on write vs on read, микс для селебрити), мессенджер (онлайн-доставка через WebSocket-шлюзы, порядок и офлайн), медиа-хостинг (загрузка → очередь → транскодинг → S3 + CDN). Знать ход целиком: от требований до эксплуатации, а не по кусочкам.

• Ключевые слова: URL shortener, лента, fan-out on write/read, селебрити, мессенджер, connection-шлюз, транскодинг, S3 + CDN.
• Спросят: собственно задание секции — «спроектируйте инстаграм/твиттер». Умею, если: собираю полный разбор ленты за 15 минут по фреймворку из 6 этапов (../classic-designs.md).

12. Эксплуатация и наблюдаемость

Финальный аккорд, отличающий senior-ответ, — и наш этап, который не режем. Наблюдаемость: golden signals (latency, traffic, errors, saturation) по каждому ярусу, p50/p95/p99 (среднее врёт, tail amplification в fan-out), SLI/SLO + error budget (99.9 % = 43 мин/мес), метрики + структурированные логи + трассировка со сквозным trace id; алерты на симптомы. Релизы: rolling, canary (1 % → 10 % → 50 % с авто-откатом), blue-green, feature flags; миграции без даунтайма — expand/contract. Принцип metrics first: любое изменение — сначала метрика, которую улучшаем.

• Ключевые слова: golden signals, SLO/error budget, canary/rolling/blue-green, expand/contract, наблюдаемость (metrics/logs/traces), headroom, shadow traffic.
• Спросят: «как поймёте, что система жива?», «как катите без простоя?». Умею, если: на этапе 6 сам называю наблюдаемость и стратегию выката, не дожидаясь вопроса (KB §10).

Сквозная нить: одна минута из жизни ленты

Как разделы работают вместе (лента новостей, 100 млн DAU). Пользователь открывает приложение: статику отдал CDN (03), запрос прошёл балансировщик к stateless-сервису ленты (03), лента нашлась в кэше — hit ratio 90 %+ (06), промах — читаем KV-зеркало, пошардированное по user_id через consistent hashing (04, 05), ответ уложился в 150 мс, потому что в горячем пути два сетевых хопа по 0.5 мс, а не поход в SQL (02). Пользователь публикует пост: сервис принял запись, событие ушло в очередь (07), фоновый fan-out раскладывает пост в кэши лент 300 подписчиков; селебрити — fan-out on read, иначе 700k вставок/с (02, 11). Упала нода кэша: виртуальные ноды переразложились, промахи ударили в БД — single-flight держит stampede (06, 08); сами посты читаются с лидера (read-your-writes), лента — eventual с лагом в секунды (09). Как мы это видим и катим — golden signals и canary (12). Это и есть «один кадр»: каждый раздел отвечает за свой участок одного и того же рассказа.

Куда углубляться: карта разделов

Файлы NN-*.md — серия статей по всем 12 разделам брифа, TASK-45.41–45.52 ✅ (завершена); справочники справа уже существуют. Порядок чтения при нехватке времени — методичка §5 (варианты А/Б/В под слоты); минимальное ядро: 01 + 02 + 11 + 08.

Связанные документы

• ../brief.md — бриф: 12 разделов с критериями «умею, если» (основа этой статьи)
• ../methodology.md — методичка: 6 этапов, речевые паттерны, план подготовки
• ../knowledge-base.md — база знаний: числа, паттерны, словарь
• ../classic-designs.md — эталонные разборы сервисов
• Серия статей: 01-interview-framework.md … 12-operations-observability.md (TASK-45.41–45.52)