title: Системный дизайн — методичка (фреймворк секции, тайминг, речевые паттерны, план подготовки) source: подготовлено 2026-09-17, TASK-45.2; основа — статья Яндекса «Как проходят архитектурные секции собеседования» (Костя Кардаманов, habr 564132); слоты — 18.09 15:30 / 21.09 15:00 / 22.09 18:00–19:00

Методичка: как проходит секция системного дизайна и как к ней готовиться

Операционный документ: как устроена секция по статье Яндекса (тем же планом интервьюер будет вести и оценивать), фреймворк ответа с таймингом на 60 минут, речевые паттерны, типовые ошибки, план подготовки под каждый из слотов и протокол тренировки. Числа и паттерны — в knowledge-base.md, разборы сервисов — в classic-designs.md. Прочитать целиком один раз, перед секцией — только §1 (тайминг), §3 (паттерны) и §7 (карточка — держать перед глазами).

1. Устройство секции: 6 этапов с таймингом

Формат. ~60 минут, один интервьюер. Задание — спроектировать крупную высоконагруженную систему (у Яндекса берут реальную — Яндекс Go; для нас заявленный фокус: крупноблочная схема сервиса класса инстаграм/твиттер + отказоустойчивость). Ключевая роль кандидата: интервьюер играет вторую скрипку и берёт инициативу только в крайних случаях — молчать и ждать вопросов нельзя, говорить и вести по плану должны мы.

План секции (структура и названия этапов — из статьи Яндекса; тайминг статья не задаёт, это наш бюджет под 60 минут):

Правила тайминга: - Если этапов не успеваем — режем детали и ресурсы (свернуть до 2–3 оценок), эксплуатацию не режем никогда: именно она отличает senior-ответ и прямо заявлена в фокусе нашей секции (отказоустойчивость). - Интервьюер может водить по своему порядку — этапы выше это внутренний компас, не сценарий для спора. Выбили нас из колеи — мысленно вернуться к плану: «требования → API → схема → детали → числа → эксплуатация». - Контрольные точки (проговаривать вслух): «требования зафиксировали, перехожу к потокам», «схема рабочая, теперь детали по самому нагруженному блоку», «по ресурсам сходится, перехожу к отказам и мониторингу».

Что оценивают (те же критерии, по которым статья описывает план): способность формализовать требования, обоснованность выбора компонентов (свойства и гарантии, а не названия), сбалансированность сложности, умение считать нагрузку и ресурсы, продуманность отказов и эксплуатации, — и что кандидат основной участник беседы: ясно, аргументированно, сам.

Взгляд в четырёх измерениях (рамка статьи, проговаривать по ходу): система не только «здесь и сейчас» — как развивается на годы (что заменить, где узкое место), и что станет причиной отказа. Плюс metrics first: любое изменение системы — сначала метрика, которую улучшаем (p95, доступность, стоимость), потом схема.

2. Фреймворк ответа по этапам

Карточка на каждый этап: цель → что на доске → что проговорить. Числа и паттерны — ссылками на knowledge-base.md (KB).

Этап 1. Требования (8 мин)

• Цель: сузить задачу и получить числа, от которых считается весь дизайн. Нехватка данных — норма: «в реальной жизни решения принимаются в условиях нехватки данных» → выдвигаем обоснованные гипотезы.
• На доске: отдельный угол — лист требований (не стирать до конца).
• Вопросы: функциональные (что делает система: пользователи, сценарии, что пропускаем) и нефункциональные: масштаб (DAU, MAU), RPS чтение/запись, latency-SLO (p95/p99), доступность (сколько девяток и на что), консистентность (что строго, что eventual), retention, лимиты/абьюз.
• Проговарить: «запишу требования, чтобы ничего не потерять». Пример диалога из статьи — читать так: «объём переходов?» — «500 тыс. RPS в пике»; «требования к скорости?» — «150 мс для 95 % чтений»; «согласованность?» — «новые ссылки строго, модификации — допускаем лаг в секунды».
• Грабли: уточнить, что НЕ строим (минус-объём экономит время: «аналитику и админку отмечаем, но не детализируем»).

Этап 2. Потоки и API (7 мин)

• Цель: понять, что система обрабатывает, и зафиксировать контракт — это уточнит характеристики блоков.
• На доске: сущности (Link, Account, Post…), 3–5 сигнатур API (POST /links, GET /{id} → 302, GET /stats), разделение control plane (управление) и data plane (горячий путь).
• Проговорить: какой протокол и почему (HTTP/2, gRPC между сервисами), идемпотентность записей, что вернём при ошибках (429, 404).
• Грабли: не рисовать сигнатуры дольше пары минут — они нужны как скелет, а не как код.

Этап 3. Крупноблочная схема (5 мин)

• Цель: каркас из 5–8 блоков: клиенты → балансировка → сервисы → хранилища → очереди → внешние зависимости.
• На доске: прямоугольники и стрелки; пометить, где control plane, где data plane, где async.
• Проговорить: путь самого горячего запроса от клиента до ответа целиком (для ленты: запрос → балансер → сервис ленты → кэш лент → ответ; фоновый fan-out — отдельно).
• Грабли: не уходить в детали до этапа 4 — тут только блоки и их роли.

Этап 4. Детали + БД (18 мин) — главная часть

• Цель: показать инженерную глубину на 1–2 самых важных компонентах (выбрать по нагрузке из требований).
• На доске: схема данных (2–4 таблицы с ключами или модель KV), устройство горячего пути, псевдокод ключевого алгоритма (обработка запроса, fan-out, лимитер).
• Проговорить (чек-лист выбора):
• Хранилище по критериям, а не по названию: «источник правды — реляционная СУБД, деньги и связи; горячее чтение не тянет SQL → read-only KV-зеркало; поиск → инвертированный индекс» (KB §3).
• Синхронизация двух хранилищ — обязательно проговорить частичный отказ: «запись в СУБД прошла, в KV нет» → outbox/CDC или коммит после majority-подтверждения + фоновая сборка мусора; 2PC называем и объясняем, почему не берём (KB §7).
• Консистентность по требованиям: «новые объекты — строго (read-your-writes: L1-кэш или читать с лидера), остальное — eventual с лагом в секунды» (KB §5, §7).
• Всё, что не нужно для ответа пользователю, — асинхронно: «время доступа и счётчики накапливаем в памяти воркера, раз в минуту — в очередь, отдельный процесс пишет в БД батчами».
• Кэш: стратегия, инвалидация, stampede (KB §4). Шардирование — только если числа показывают, что надо, и через лестницу «индексы → реплики → кэш → шарды» (KB §6).
• Грабли: не проектировать «всё» — детализируем горячий путь, остальное держим крупно; сложность балансируем: «если есть стандартное решение — берём его, не усложняем без необходимости».

Этап 5. Ресурсы и узкие места (7 мин)

• Цель: показать, что дизайн сходится арифметически, и найти бутылочное горлышко до того, как его нашёл интервьюер.
• На доске: 3–4 расчёта с формулами: QPS avg/peak, storage с retention и репликами, bandwidth, число нод.
• Проговорить: «допущение → формула → число → вывод» (KB §2). Latency numbers — для обоснований: «round-trip внутри ДЦ 0.5 мс, поэтому три синхронных хопа в горячем пути — это уже треть бюджета 150 мс» (KB §1.2).
• Выводы-формулы: «это терабайты — влезает в одну ноду, узкое место не storage, а RPS на чтение → кэш/зеркало»; «egress гигабиты → CDN»; «fan-out 700k вставок/с → доставка и есть дизайн, а не пост».
• Грабли: не считать молча; если число «не сходится» — это не провал, а сюжет: «storage ок, но CPU на SSL — доминанта, вот как меняю дизайн».

Этап 6. Эксплуатация (10 мин)

• Цель: показать production-зрелость. Заявленный фокус секции — отказоустойчивость, этот этап обязателен.
• На доске: топология (2–4 ДЦ, балансировка), таблица «узел → отказ → что происходит → что видим в метриках».
• Проговорить (по каждому ключевому узлу): «что будет, если упадёт балансировщик / нода data plane / primary СУБД / очередь?»; graceful degradation — «чем жертвуем: отдаём кэш, отключаем статику, ограничиваем лимиты»; перегрузка в разы: rate limiting, load shedding, blacklist подозрительного трафика (KB §9).
• Мониторинг: golden signals по классам узлов, p50/p95/p99, коды ответов с защитой от шума, SLO + error budget; логи — сэмпл/ротация/холодное хранилище, трассировка каждого k-го запроса (KB §10).
• Релизы: canary/rolling, миграции expand/contract, тестовый контур с дублем k-х запросов из прода.
• Финал — вернуться к листу требований: «проверим требования: SLO по латентности обеспечен запасом 30→10 мс, доступность чтения — N+1 по всем ярусам, лимиты — rate limiter; вот чем каждое требование контролируем метрикой». Это ключевой ход, который почти никто не делает.

Сверка с фреймворком Alex Xu (гл. 3, TASK-45.38)

Книга даёт каркас «4 шага»; наш 6-этапный фреймворк — его детализация. Полезно знать соответствие (если интервьюер опирается на книгу):

Шаг 4 у Alex Xu — «поговорить об узких местах, мониторинге и что улучшить при наличии времени»; наш ход «вернуться к листу требований» — это шаг 4, выполненный сильнее стандартного. Do/don't из книги: не молчать (думать вслух), уточнять до проектирования, работать с интервьюером, а не в одиночку, скромность в оценках.

3. Чек-лист речевых паттернов

Говорить «инженерным языком секции»: гипотезы явно, трейдоффы вслух, сложность минимальная, гарантии вместо брендов.

Шаблоны трейдоффов (источник 4, habr 516604 — «добавили элемент → решает проблему → платим ценой»; проговаривать даже когда очевидно): заготовка — «добавляем X, это решает ⟨нагрузку / объём / надёжность⟩, платим ⟨поддержкой / консистентностью / сложностью⟩». Готовые пары «даёт → платим»:

Быстрая самопроверка речи (после каждой тренировки по протоколу §6): слышал ли я сам от себя — ≥ 2 гипотезы, ≥ 3 трейдоффа (можно из таблицы выше), ≥ 3 числа с формулой, ≥ 1 «не усложняю», гарантии вместо брендов, явные чекпоинты, возврат к требованиям.

Правила поведения на секции (источник 5, видео Gabbard — конспект в materials/jackson-gabbard-ep06.md)

Пять правил сверх таблицы паттернов; источник — интервьюер Facebook, аргументация — кейсы реальных секций (§7 его конспекта):

1. Водительское кресло. «You are in the driver's seat… treat it like a tech talk»: мы объясняем интервьюеру, как будет устроена система, а не ждём указаний. «И что дальше?» должен звучать от интервьюера — если тянем его от нас, это минус независимо от качества кода (кейс: панель голосовала «берём», директор зарубил: «8 лет опыта — и mindset “I don't know what's next”»). Закреплено в §1: кандидат — основной участник беседы.
2. Funny money → рабочие числа. Массовые круглые числа из вводной (500 млн MAU) — не для железа. Проговариваем конверсию вслух: MAU → DAU (допущение 70 %) → час пика (70 % DAU) → одновременные (÷ 3 600) → ноды (÷ ёмкость ноды). Пример из видео: 500M MAU → 350M DAU → 245M/час пика → ~68k одновременных → ~68 серверов.
3. Ошибка ×2 — не провал. Числа — допущения, а не психометрия: мало серверов — докупим, много — пригодится на росте; провал — ошибка в порядок и больше. Каждое число сопровождаём словом «допущение» (паттерн «гипотеза при нехватке данных» из таблицы выше).
4. Хинт лучше ступора. Застряли — вслух фиксируем, где мы («давай зафиксирую, где мы»), и если не сдвинулись — просим подсказку. Хинт слегка ослабляет оценку, но 5 минут молчания у доски ослабляют сильнее (ошибка №2 из §4); сильный финиш после подсказки весит больше.
5. Незнакомое — назвать вслух. Не убегать от незнакомых частей: коротко проходим то, что знаем хорошо, и честно помечаем края («эта часть мне знакома хуже — вот как бы её раскапывал»). Секция добывает именно сигнал о краях знаний; «это не моя специальность» = сигнал отсутствия лидерства.

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

4. Топ-10 ошибок кандидатов

5. План подготовки под слоты

Слоты: пт 18.09 15:30 / пн 21.09 15:00 / вт 22.09 18:00–19:00. Три варианта — по тому, какой слот берём. Приоритет тренировки: URL shortener (эталон статьи, он же вероятный формат) → лента новостей (инстаграм/твиттер — заявленный фокус) → мессенджер → медиа-хостинг.

Порядок чтения материалов

DDIA — не читать подряд перед секцией: только по карте (KB §12): до первой секции гл. 1, 3, 5, 6; между 18.09 и 21.09 — гл. 7–9; перед 22.09 — гл. 11. Если секция 18.09 — DDIA не трогаем вовсе, время дороже. Нумерация — по 1-му изд. (рус. перевод); для 2-го издания — сдвиг на +1 (гл. 6–10 ядро), соответствие — materials/ddia-map.md §0, полный текст 2-го издания с выжимками — materials/ddia-2ed/ (TASK-45.39): выжимки глав 6–10 удобно читать как «конспект за 5 минут» вместо перечитывания глав.

Дополнение (TASK-45.12): в треке появилась подборка learn-system-design — полный индекс и приоритеты в materials/learn-system-design-index.md (задачи 45.11–45.37). Встраивание в план: в вариант А — карточка-памятка §7 этого документа (15 мин вечером, она же перед глазами на секции; источник — TASK-45.22) и шпаргалка vasanthk 45.23 (15 мин), и проход KB §13 (5 мин); в Б — плюс статья Поломодова 45.20 (60 мин), одно видео мока karpov.courses 45.26 (40 мин; конспект с топ-3 разборами — materials/lsd-karpov-mocks.md), числа 45.25 (10 мин); в В — плюс видео Поломодова/Тинькофф 45.27 (60 мин), habr 655663 45.21 (45 мин), визуальный повтор system-design-101 45.15 по слабым местам. Каты 45.29 (§6.5): в вариантах Б/В — один раунд по кате №1 или №2 накануне слота (стресс-тест незнакомого брифа). Учебники и подписки (45.11, 45.13–45.19, 45.30–45.37) — только после секций.

Вариант А — «Завтра» (слот пт 18.09 15:30), интенсив ~4 ч

• Чт 17.09 вечер (2.5–3 ч): 1. Статья Яндекса целиком (60–75 мин) — конспективно: 6 этапов, фразы, разбор URL shortener. 2. Этот документ §1–4 (20 мин). 3. KB §1–2: числа и back-of-envelope — 3 примера из §2.2–2.4 прогнать вслух с формулами (45 мин). 4. Одна тренировка у доски: URL shortener по протоколу §6 (60 мин) + self-review по рубрике (10 мин).
• Пт 18.09 утро (30–40 мин): шпаргалка KB §11 + чек-лист паттернов §3 этого документа; легкий прогон примера ленты (KB §2.3). После 12:00 ничего нового не читать.
• Важно: 18.09 — рабочий формат «с листа»: цель — не знать всё, а провести секцию по фреймворку без пауз. URL shortener, прогнанный вслух по 6 этапам, покрывает 80 % успеха.

Вариант Б — «Понедельник» (слот пн 21.09 15:00), ~8 ч на 4 дня

• Чт 17.09 вечер: пункты 1–3 из варианта А (≈2.5 ч).
• Пт–сб: KB §3–11 / Primer гайд (90 мин); habr 516604 (30 мин); DDIA гл. 1, 3 (по 45–60 мин); тренировка 1: URL shortener.
• Вс: DDIA гл. 5, 6; classic-designs §2 лента; тренировка 2: лента новостей (60 мин) + self-review.
• Пн до 12:00: шпаргалки, чек-лист §3, спринт 20 мин у доски (крупноблочная схема ленты с нуля). Дальше — пауза, к 15:00 прийти свежим.

Вариант В — «Вторник» (слот вт 22.09 18:00/19:00), полный курс ~12 ч

• Чт–пт: как в Б (пункты 1–3 + KB §3–11 + habr 516604); тренировка 1: URL shortener.
• Сб–вс: видео Gabbard (40 мин); DDIA гл. 5–6, затем 7; classic-designs: мессенджер; тренировки 2–3: лента, мессенджер.
• Пн: DDIA гл. 8–9 (конспект по KB §12); mock-сессия с ассистентом 60 мин + разбор (§6.3).
• Вт: DDIA гл. 11 (потоковая обработка — прямо ложится на вопросы про очереди); лёгкий спринт у доски; к 18:00 — свежим, перед секцией только шпаргалки.

Во всех вариантах: последняя полная тренировка — не позднее чем за 3 часа до секции; записи тренировок — в training/ рядом с этим файлом (по образцу ../algo-exam/).

6. Протокол само-тренировки

6.1 Формат раунда

1. Место: настоящая доска или большой лист (статья прямо советует: «большой лист бумаги или маркерную доску»). Телефон — на запись голоса: проговаривать вслух, как на секции, иначе тренировка не засчитывается.
2. Билет: один сервис из classic-designs.md (URL shortener, лента, мессенджер, медиа-хостинг). Порядок — случайный; повтор — по слабым местам прошлых раундов.
3. Таймер 60 минут (при нехватке времени — спринт 40: те же этапы, детали и ресурсы свёрнуты). Клацнул старт — дальше как на секции.
4. Доска фотографируется, голосовая запись сохраняется — до разбора не пересматривать (как в algo-exam: разбор только в конце раунда).
5. Self-review сразу после раунда (10 мин): рубрика ниже + чек-лист. Затем сверить с эталоном из classic-designs.md и записать 3 улучшения.

6.2 Рубрика self-review (0–3 за каждый из 6 этапов, максимум 18)

Порог готовности к слоту: сумма ≥ 13/18, этап 6 (эксплуатация) ≥ 2, тайминг соблюдён ±3 мин. Ниже порога — повтор раунда по тому же сервису на следующий день: цель повторного раунда — не вспомнить разбор, а удержать тайминг и паттерны речи.

Чек-лист после раунда (да/нет): требования записаны и не стёрты? ≥ 3 расчёта вслух с формулами? каждый ключевой узел получил сценарий отказа? эксплуатация уложилась в 10 минут? финальный возврат к требованиям прозвучал? паттерны §3 — минимум по одному разу?

6.3 Mock-сессия с ассистентом

Для раундов 2–3 и перед слотами 21–22.09 предлагаю mock-сессию со мной: я играю интервьюера по протоколу статьи — - выдаю билет (сервис + масштаб), отвечаю на уточняющие вопросы нейтрально и в стиле статьи («500 тыс. RPS в пике», «четыре девятки на чтение»), на трейдоффы не реагирую; - слежу за таймингом молча, могу один раз напомнить «время»; - в конце — разбор по 6 этапам с баллами рубрики, список слабых мест и 3 конкретных улучшения к следующему раунду. Фидбек только после завершения раунда (правило как в ../algo-exam/README.md).

Запуск: сказать «давай mock по системному дизайну» и указать сервис или «случайный».

6.4. Внешние мок-сессии: Pramp → Aced (Exponent Practice)

Материал 24 (TASK-45.28, проверено 17.09.2026). Pramp как отдельная платформа больше не существует: с июля 2024 все сессии проводятся на Exponent Practice — сайт переименован в Aced, pramp.com остался витриной-редиректом на tryexponent.com/practice. Старые аккаунты Pramp привязываются к Aced, для новых — обычная регистрация.

Формат сессии (по FAQ платформы): - живое видео 1:1 на сайте; партнёр подбирается автоматически (расписание, роль, уровень опыта, история сессий) — выбирать нельзя, но есть режим «practice with a friend»; - ~60 минут: 30 мин в роли кандидата + 30 мин в роли интервьюера, роли случайны, переключение в середине; комната доступна до 2 ч; - для System Design код-редактора нет (он только для DSA/SQL/Frontend): вопросы предлагаются из базы реальных FAANG-вопросов до и во время сессии, можно принести свой; - после сессии — взаимный фидбек по рубрике; AI-оценка транскрипта — платная фича, не нужна; - peer-практика бесплатна: у free-аккаунта ежемесячные кредиты, на наши 1–2 сессии хватает.

Сетка SD-слотов — ежедневно в 02:00, 08:00, 12:00, 18:00 PT (сентябрь: PDT = UTC−7, МСК = PT + 10) → 12:00, 18:00, 22:00, 04:00(+1) МСК. Удобные для нас: 18:00 и 22:00 МСК. Зайти в комнату можно за 10 мин до старта; если пара не собралась — сессия отменяется, кредит возвращается.

Оценка под нашу задачу:

Рекомендация: это дополнение к §6.3, а не замена. Мок с ассистентом калибрует под яндекс-формат (6 этапов, рубрика, русский), Aced добавляет то, чего дома нет, — незнакомца и живой темп. Для зарубежного трека — обязательный инструмент и после этой секции.

План сессий (по слоту этапа 2):

Как проводить сессию: - в роли кандидата: попросить тему из наших приоритетов («news feed / Instagram-like», запасная — URL shortener); идти по тому же кольцу §1 с таймингом вдвое короче — требования 5 → API/схема 8 → детали 9 → числа и отказы 8; паттерны §3 те же; - в роли интервьюера: дать партнёру его вопрос из базы, наблюдать и фиксировать, что сам искал бы в ответе; фидбек — конкретный, по-честному; - после: 10 мин self-review по чек-листу §6.2 (переносимое: паттерны речи, ≥ 3 числа с формулой, трейдоффы) + 3 улучшения записать в training/.

Регистрация (действие пользователя, ~5 мин): tryexponent.com/practice → Sign up (Google или email) → Schedule practice session → тип System Design, дата/время (18:00 или 22:00 МСК), уровень → подтверждение и напоминания на email → за 10 мин до старта вернуться на страницу Practice → Join. Десктоп (мобильные не поддержаны), Chrome/Firefox/Edge, разрешить камеру и микрофон; видео — P2P WebRTC, нужен стабильный канал; при недоступности сайта из РФ — VPN.

6.5. Архитектурные каты: раунд по незнакомому брифу

Материал 25 (TASK-45.29, проверено 18.09.2026). Architectural Katas — банк упражнений «спроектируй систему по брифу заказчика»: architecturalkatas.com (Ted Neward, 38 кат) и nealford.com/katas (Neal Ford, 20 кат). Ката — это бриф без эталона и без подсказок: ближайший к реальной секции формат тренировки, потому что на интервью тоже дают незнакомый бриф. Полный разбор сборников, тексты кат и резерв — materials/architectural-katas.md.

Выбранные каты (критерий: веб-масштаб с числами + не пересекаются с эталонами classic-designs.md):

Резерв (в materials/architectural-katas.md §4): Gird The Grid (четыре девятки, телеметрия), Who's Your Daddy? (граф), Make the Grade (batch/очереди).

Протокол раунда по кате — тот же §6.1, отличия три: 1. Билет = текст каты (EN, читается в первые 2 минуты раунда и остаётся перед глазами). Брифы — в materials/architectural-katas.md §3, перепечатывать не надо. 2. Масштаб не полный — это фича, не баг: недостающие числа фиксируются как допущения на этапе 1 и записываются в угол доски вместе с требованиями («допустим, 5% мест возвращаются в продажу…»). В моке с ассистентом (§6.3) вопросы задаются ему — он играет модератора-заказчика, как в правилах оригинала. 3. Эталона нет — self-review §6.2 идёт по чек-листу этапов и KB-паттернам: какие разделы брифа ката покрыла, где числа с формулами, где трейдоффы; сверка с classic-designs.md — только по переносимым паттернам (например, fan-out из ленты — в пуш ставок аукциона).

Место в подготовке: ката — стресс-тест после эталонов, не вместо них. Порядок: 1–2 раунда по classic-designs.md (каркас ответа + есть с чем сверять) → 1 раунд по кате №1 или №2 накануне слота. Ката №3 — если останется время в варианте В (вт 22.09) или после секции. Правило оригинала «any technology is fair game — just be prepared to defend its use» — буквально наш §3: любой выбор технологий, но каждый defended.

7. Карточка-памятка на секцию

Адаптация шаблона LeetCode 229177 («My System Design Template», конспект — materials/lsd-leetcode-template.md) под 6 этапов Яндекса: позвоночник — этапы §1, начинка — чек-листы шаблона. Назначение — не учить новое, а собирать изученное перед глазами: открыть рядом на секции и на каждой тренировке, идти по пунктам сверху вниз. Фразы курсивом — говорить вслух как есть. Расшифровки — §2 этого документа, числа — KB.

Перед стартом: угол доски — лист требований (не стирать до конца); таймер; руль у нас — «и что дальше?» должно звучать от интервьюера.

Этап 1. Требования — 8 мин

• [ ] Use cases, 3–5 сценариев + что НЕ строим (аналитику/админку отметили — не детализируем)
• [ ] Кто и сколько: DAU, паттерны использования (вечерние пики? read-heavy?)
• [ ] Грубые числа: RPS чтение/запись, read/write ratio (KB §2.1)
• [ ] SLO: латентность p95/p99, доступность — сколько девяток и на что
• [ ] CAP-декларация: «консистентность — строгая для X, eventual для Y; доступность — репликация и failover»
• [ ] «Запишу требования в угол доски, к ним вернёмся в конце»

Этап 2. Потоки и API — 7 мин

• [ ] Сущности + 3–5 сигнатур API (read- и write-сценарии)
• [ ] Control plane vs data plane — горячий путь отдельно
• [ ] Протокол (HTTP/gRPC), идемпотентность записи, коды ошибок
• [ ] «API — скелет, не код: две минуты — и к схеме»

Этап 3. Крупноблочная схема — 5 мин

• [ ] 5–8 блоков: DNS → LB → шлюз/сервисы → кэш → БД → очереди
• [ ] Путь горячего запроса чтения и записи — каждый целиком, отдельно
• [ ] Базовый алгоритм одной строкой (fan-out on write / on read, …)
• [ ] «Схема рабочая — перехожу к деталям самого нагруженного блока»

Этап 4. Детали + БД — 18 мин

Детализируем 1–2 блока по узкому месту из требований; по каждой компоненте — A/C/S-история (доступность, консистентность, масштаб). Чек-лист меню (что прогнать мысленно):

• [ ] БД по гарантиям, не по названию (KB §3); мнемоника шаблона: RAM-bounded → Redis/Memcached; AP → Cassandra-класс; CP → HBase/MongoDB
• [ ] Лестница масштабирования: индексы → реплики → кэш → шарды (KB §5–6); RDBMS-приёмы: master-slave/master-master, federation, шардирование, денормализация
• [ ] Кэш: паттерн (aside/through/behind) + вытеснение (LRU) + защита от stampede; слои: application → database (дефолт СУБД) → in-memory (KB §4)
• [ ] Асинхронность: всё не нужное для ответа — очереди, батчи, back pressure (KB §8)
• [ ] Периферия меню: DNS, CDN (push/pull), LB (L4/L7; реализация: software — дефолт, smart client, hardware), reverse proxy, service discovery — называем, если ложится на нагрузку
• [ ] Трейдофф на каждое решение: «два варианта: A проще, B строже; беру A, платим Y, компенсирую Z»

Этап 5. Ресурсы и узкие места — 7 мин

• [ ] QPS avg/peak; storage с retention и репликами; bandwidth; RAM под кэш; ноды (KB §2)
• [ ] Послойный justify: throughput каждого слоя + латентность между слоями → бюджет против SLO («три синхронных хопа × 0.5 мс внутри ДЦ — треть бюджета 150 мс»)
• [ ] Узкое место раньше интервьюера: «storage ок — горло в read-RPS → кэш/зеркало»
• [ ] «Допущение → формула → число → вывод»

Этап 6. Эксплуатация — 10 мин (в шаблоне отсутствует — наше добавление)

• [ ] Топология: 2–4 ДЦ, балансировка; по каждому узлу: упал → что происходит → что в метриках
• [ ] Перегрузка в разы: rate limiting, load shedding, graceful degradation (KB §9)
• [ ] Мониторинг: golden signals, SLO + error budget; релизы: canary, expand/contract (KB §10)
• [ ] Security одним блоком: authn/z, лимиты, абьюз (KB §13.7)
• [ ] Финал: возврат к листу требований — каждое закрыто метрикой. «Сверимся: SLO обеспечен запасом …, доступность — N+1, лимиты — rate limiter»

Самопроверка после секции/тренировки: ≥ 2 гипотезы, ≥ 3 трейдоффа, ≥ 3 числа с формулой, гарантии вместо брендов, чекпоинты прозвучали, возврат к требованиям состоялся (критерии — §3, §6.2).

Что печатать на секцию (решение по материалам 18–19, TASK-45.22/45.23; конспекты materials/lsd-leetcode-template.md, materials/lsd-cheatsheet-vasanthk.md): один лист А4 с двух сторон — лицевая: эта карточка §7 (позвоночник 6 этапов + чек-листы), оборот: KB §1.2 (латентность) + KB §11 (мини-шпаргалка «что назвать»). Vasanthk-шпаргалку и LeetCode-шаблон целиком не печатать: их шаги дублируют §1/§7, фронтенд-разделы не про нашу секцию, уникальное (кэш по слоям, типы LB) уже внесено в чек-лист этапа 4. Смысл листа тот же, что у шпаргалок: не учить, а собирать изученное перед глазами.

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

• knowledge-base.md — числа, back-of-envelope, хранилища, паттерны, карта DDIA (TASK-45.1)
• classic-designs.md — эталонные разборы: URL shortener (по статье), лента, мессенджер, медиа-хостинг (TASK-45.3)
• ../interview-materials.md — карта материалов по вакансии
• ../algo-exam/README.md — протокол экзаменации по алгоритмам (этап 1; рубрика и правила раунда адаптированы отсюда)
• Pramp → Aced (Exponent Practice) — внешние peer-моки на английском: оценка формата и план сессий — §6.4 (TASK-45.28)
• Architectural Katas — банк незнакомых брифов для раундов на доске: выбор кат и протокол — §6.5, полный разбор — materials/architectural-katas.md (TASK-45.29)
• Источник: К. Кардаманов, «Как проходят архитектурные секции собеседования в Яндексе» — habr 564132 (конспект в materials/, TASK-45.5)