---
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 минут):

| # | Этап | Раздел статьи | Что происходит | Тайминг |
|---|------|---------------|----------------|---------|
| 1 | **Требования** | «Уточнение задачи: формализация требований, оценка аудитории, порядок нагрузки» | Функциональные и нефункциональные требования: DAU/RPS, latency-SLO, доступность, консистентность, лимиты. Всё **записывать** — в конце вернёмся | 8 мин |
| 2 | **Потоки и API** | «Потоки данных, API» | Что входит/выходит, основные сущности, сигнатуры базовых методов, control plane vs data plane | 7 мин |
| 3 | **Крупноблочная схема** | «…основные блоки системы» | Из каких сервисов/компонент состоит система, кто с кем говорит, где хранится, где очередь | 5 мин |
| 4 | **Детали + БД** | «Детальная схема с компонентами и их ролями, устройство наиболее важной части, структура базы данных» | Устройство 1–2 самых важных/нагруженных блоков, схема данных (DDL или модель), синхронизация хранилищ, псевдокод ключевого алгоритма | 18 мин |
| 5 | **Ресурсы и узкие места** | «Оценка объёма необходимых вычислительных ресурсов, поиск узких мест» | Back-of-envelope: storage/RPS/bandwidth/серверы, latency numbers, где бутылочное горлышко и что с ним делать | 7 мин |
| 6 | **Эксплуатация** | «Топология сервиса, вопросы эксплуатации: балансировка, обработка отказов, мониторинг, обслуживание, работа в экстремальных условиях» | ДЦ и балансировка, сценарии отказов по каждому узлу, мониторинг/метрики, релизы и миграции, поведение при превышении нагрузки в разы | 10 мин |
| — | Доп. вопросы / вопросы кандидата | «Дополнительные вопросы» | Буфер: углубление в узкое место, трейдоффы фреймворков, вопросы кандидата | 5 мин |

**Правила тайминга:**
- Если этапов не успеваем — режем **детали и ресурсы** (свернуть до 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-этапный фреймворк — его детализация. Полезно знать соответствие (если интервьюер опирается на книгу):

| Alex Xu «4 шага» | Наши этапы | Что совпадает / что у нас глубже |
|---|---|---|
| 1. Понять задачу и масштаб | Этап 1 | то же: функциональные/нефункциональные, вопросы интервьюеру; у нас + явные числа-гипотезы и минус-объём |
| 2. Общее решение + согласие | Этапы 2–3 | то же: API и high-level схема до деталей; у нас + control/data plane |
| 3. Глубокое проектирование | Этапы 4–5 | то же: приоритеты интервьюера; у нас + обязательная арифметика (этап 5) |
| 4. Подведение итогов | Этап 6 | у нас шире: узкие места + мониторинг + релизы + возврат к листу требований |

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

---

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

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

| Паттерн | Формулировка | Зачем |
|---------|--------------|-------|
| Гипотеза при нехватке данных | «Вводных нет — выдвигаю гипотезу: DAU 100 млн, пик ×3 к среднему. Поправьте, если есть реальные цифры» | Статья: гипотезы выдвигать можно и нужно; интервьюер слышит мышление, а не ступор |
| Оценка по формуле | «Допущение: 100 млн DAU × 10 чтений/сутки → 12k QPS avg, пик ~35k. Вывод: …» | Число без формулы не оценивается; формула показывает, что это расчёт, а не догадка |
| Трейдофф | «Два варианта: A — быстрее и проще, B — строже и дороже. Наши требования — X, поэтому беру A, платим Y, компенсируем Z» | Каждое решение — с альтернативой и ценой; «взвешенно и осознанно» |
| Гарантии вместо названий | «Конкретную БД не принципиализирую: нужен in-memory KV с репликацией, ~100k RPS на ноду и лагом < 1 с — подойдут Redis/Aerospike-класс» | «Нам важнее свойства и предоставляемые системой гарантии, чем конкретное название» |
| KISS | «Не усложняю без необходимости: здесь стандартный nginx/IPVS, самописное — только то, чего нет в готовом» | «Система должна быть минимально сложной и дешёвой в разработке и эксплуатации» — прямой критерий статьи |
| Критический путь | «Это не нужно для ответа пользователю → из горячего пути убираем: накапливаем в памяти, батчами раз в минуту, отдельный процесс пишет» | Главный приём статьи (счётчики, время доступа, лимиты) — асинхронизация всего второстепенного |
| Metrics first | «Метрика, которую улучшаем: p95 редиректа ≤ 150 мс / доступность чтения 99.99 %» | Подход Яндекса; каждое изменение — от метрики |
| Управление интервью | «Требования зафиксировали — перехожу к API». «Детализировать глубже X или идём к ресурсам?». «Три минуты — перехожу к отказам, вернусь к деталям, если успеем» | Кандидат — хозяин беседы; чекпоинты держат нас в тайминге, вопрос даёт интервьюеру руль легально |
| Возврат к требованиям | «Сверимся с листом: SLO закрывает запас 30→10 мс; 4 девятки — N+1 на каждом ярусе; лимиты — rate limiter. Каждое требование контролируется метрикой …» | Кольцо секции: начали требованиями — закончили проверкой; маркер senior-ответа |

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

| Что добавили | Даёт | Платим |
|--------------|------|--------|
| новый компонент / больше узлов | нагрузку, скорость ответа | поддержкой и деплоем |
| шардирование | нагрузку и объём | перешардированием в будущем |
| репликацию | нагрузку и надёжность | протухшими значениями, доступность vs консистентность |
| кэш | нагрузку | протухшими значениями, cache coherency |
| своё решение | заточку под себя | его надо сперва написать |
| готовое решение | оно уже есть | в нём надо разбираться |

Быстрая самопроверка речи (после каждой тренировки по протоколу §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 ошибок кандидатов

| # | Ошибка | Как выглядит | Как избежать |
|---|--------|--------------|--------------|
| 1 | Прыгнуть в схему без требований | Рисуем коробки на 20-й секунде, потом переделываем | 5–8 минут требований — это часть ответа; если данных нет — гипотезы (§3) |
| 2 | Молчать и рисовать про себя | Долгие паузы, интервьюер вынужден тянуть | Думать вслух; кандидат — основной докладчик. Молчание > 15 с — проговорить, что сейчас делаем |
| 3 | Не записать требования и не вернуться к ним | В конце секции требования «потерялись», проверять нечего | Угол доски под требования; финальный шаг этапа 6 — сверка с листом |
| 4 | Усложнение без необходимости | Самописный лимитер-кластер с консенсусом там, где хватит снимка в СУБД | «Как бы я делал в проде?»; стандартное решение по умолчанию; сложность — только от требований |
| 5 | Названия вместо свойств | «Возьмём Cassandra» — без гарантий и критериев | Гарантии/класс → критерии → примеры-кандидаты (KB §3) |
| 6 | Решения без альтернатив | «Делаем так» — и всё | Каждое ключевое решение через трейдофф-фразу (§3); минимум 3 за секцию |
| 7 | Нет арифметики вообще или числа без вывода | «Там терабайты» — откуда? | Back-of-envelope по формуле из KB §2; ≥ 3 расчёта за секцию, вслух |
| 8 | Синхронный критический путь | Счётчик обновляется в БД на каждом запросе | Фильтр «нужно ли это для ответа пользователю?» — всё остальное асинхронно/батчами |
| 9 | Застрять в деталях, не успеть эксплуатацию | 40 минут в деталях, отказы — на бегу | Жёсткий тайминг §1; чекпоинты; эксплуатацию не режем, режем детали |
| 10 | Не рассмотреть частичные отказы хранилищ | Два хранилища, синхронизация «как-нибудь реплицируется» | Проговорить расхождение явно: outbox/majority-коммит + GC, идемпотентность потребителя (KB §7–8) |

---

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

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

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

| # | Материал | Зачем | Время |
|---|----------|-------|-------|
| 1 | Статья Яндекса (habr 564132) | Каркас секции + эталонный разбор URL shortener + словарь оценочных критериев. Читать с карандашом: отмечать 6 этапов и фразы-паттерны | 60–75 мин |
| 2 | `methodology.md` (этот документ) §1–4 | Фреймворк, речевые паттерны, ошибки | 20 мин |
| 3 | `knowledge-base.md` §1–2 + Primer Appendix (TASK-45.6) | Числа и back-of-envelope до автоматизма — это скелет этапа 5 | 45 мин |
| 4 | `classic-designs.md` §1 URL shortener (TASK-45.3) | Сборка полного разбора по 6 этапам | 30 мин |
| 5 | `knowledge-base.md` §3–11 + Primer полный гайд (TASK-45.7) | Паттерны: хранилища, кэш, шардирование, консистентность, очереди, отказы | 90 мин |
| 6 | habr 516604 «Как я научился проходить архитектурные секции» (TASK-45.8) | Взгляд проходца: чек-листы, психология | 30 мин |
| 7 | Видео Gabbard (TASK-45.9) | Калибровка ожиданий + правила поведения (§3, «водительское кресло», хинты); конспект — `materials/jackson-gabbard-ep06.md` | 40 мин |
| 8 | DDIA по карте KB §12 (TASK-45.10) | Глубина для раундов 2–3 и последующих секций | по 1–2 гл/день |

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)

| Балл | Значение |
|------|----------|
| 3 | Этап закрыт полностью: трейдоффы проговорены, числа с формулами, гарантии вместо названий |
| 2 | Этап закрыт частично: есть схема/решения, но без альтернатив, чисел или последствий отказов |
| 1 | Поверхностно: названо, не обосновано |
| 0 | Пропущен (типично: эксплуатация — см. ошибку №9) |

**Порог готовности к слоту:** сумма ≥ 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 мин до старта; если пара не собралась — сессия отменяется, кредит возвращается.

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

| За | Против |
|---|---|
| Живой незнакомый человек: стресс, темп, «думать вслух под взглядом» — то, чего не даёт ни доска, ни мок с ассистентом | Только английский; секция будет на русском |
| Роль интервьюера: чужой ответ со стороны — калибрует, что выглядит сильным, а что слабым | Партнёр — такой же кандидат, не интервьюер Яндекса: рубрика и пул вопросов не яндекс-формат |
| Вопрос из FAANG-пула + можно принести свою тему (news feed — наш фокус) | Матч не гарантирован, сетка жёсткая — бронировать заранее |
| Английская SD-лексика — прямо работает на зарубежный трек (GitLab, Pennylane, Cleo) | Кандидатских минут всего 30 из 60: половина сессии уходит на интервьюирование партнёра (тоже полезно, но считать в бюджете) |

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

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

| Слот | Сессии Aced | Примечание |
|---|---|---|
| А — пт 18.09 15:30 | пропускаем | поздно регистрироваться и рисковать вечером перед секцией; максимум — присоединиться к сегодняшней 22:00 МСК при запасе сил |
| Б — пн 21.09 15:00 | 1 сессия: **сб 19.09 22:00 МСК** | при несобравшемся матче — повтор вс 20.09 22:00; регистрация до утра субботы |
| В — вт 22.09 18:00 | 2 сессии: **вс 20.09 22:00 + пн 21.09 18:00 МСК** | вторая — за сутки до секции; после неё только шпаргалки |

**Как проводить сессию:**
- в роли кандидата: попросить тему из наших приоритетов («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](https://www.architecturalkatas.com/) (Ted Neward, 38 кат) и [nealford.com/katas](https://nealford.com/katas/) (Neal Ford, 20 кат). Ката — это бриф без эталона и без подсказок: ближайший к реальной секции формат тренировки, потому что на интервью тоже дают незнакомый бриф. Полный разбор сборников, тексты кат и резерв — `materials/architectural-katas.md`.

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

| # | Ката | Домен | Что давит | Когда брать |
|---|---|---|---|---|
| 1 | **Concert Comparison** | продажа билетов на концерты | burst до 10 000 RPS, «не продать место дважды», эластичность; контекст сам требует сравнить Space-Based vs Microservices с трейдоффами | основная; первая |
| 2 | **I Can Haz Cheezborger?** | UGC-платформа интернет-трендов | read-heavy ~1000:1 (миллионы читателей), CDN/кэш, асинхронная модерация, аналитика | вторая |
| 3 | **Going, Going, Gone!** | аукционы online + live, real-time | порядок ставок (linearizability), fan-out пуша, видео, платежи, аудит после иска о мошенничестве | третья, самая сложная |

Резерв (в `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)