---
title: Конспект источника 4 — В. Комаров «Как я научился проходить архитектурные секции» (habr 516604)
source: https://habr.com/ru/post/516604/
author: Виктор Комаров (victor_k), 26.08.2020
конспект: подготовлено 2026-09-17, TASK-45.8; взгляд «проходца» — дополняет официальный взгляд интервьюера (источник 1, habr 564132); план, шаблоны трейдоффов и правила по числам перенесены в methodology.md §2–3 и knowledge-base.md §1.2
статус: опыт кандидата (не официальный документ Яндекса); формулировки плана и трейдоффов — из статьи, увязка с нашими материалами — наша
---

# Источник 4: «Как я научился проходить архитектурные секции» (habr 516604)

Второй взгляд на ту же секцию. Источник 1 (статья Яндекса) объясняет, **как интервьюер ведёт секцию и что оценивает**; этот — **как кандидат готовился и что реально говорил у доски**. Автор независимый, потратил на подготовку ~2 недели. Главная ценность — другой маршрут рассказа (цикл вокруг узкого места) и готовые фразы-трейдоффы, которых в официальной статье нет. Читать после источника 1 (каркас) и перед тренировками.

Связь с подготовкой: `../methodology.md` §3 (шаблоны трейдоффов), §5 (пункт 6 порядка чтения, 30 мин), §6 (практика), `../classic-designs.md` (запчасти-паззлы → билеты), `../knowledge-base.md` §1.2 (числа).

---

## 1. План из 7 пунктов (+ бонус)

Автор подчёркивает: **план важно иметь** — даже если свернёшь не туда, общая структурированность сыграет на руку. Формулировки — из статьи; «наш этап» — соответствие 6 этапам `methodology.md` §1.

| # | Пункт плана (формулировка статьи) | Что на доске | Наш этап |
|---|-----------------------------------|--------------|----------|
| 1 | Собрать список ключевых фич и выписать их **в углу доски** — «простой трюк, чтобы не забыть важное ограничение или допущение» | угол под фичи и допущения, не стирать | 1. Требования |
| 2 | Понять технические характеристики: **ожидаемый RPS, диапазон допустимых времён ответа, ожидания по консистентности и надёжности** | лист требований и цифр | 1. Требования |
| 3 | Собрать **простейшее решение на одну машину**, которое хоть как-то работает («начинать с 20 датацентров не нужно — гораздо лучше прийти к этому постепенно») | клиент → сервер → БД, честно просто | 3. Крупноблочная схема |
| 4 | Найти **единую точку отказа или узкое место** по производительности | пометить на схеме: где сломается под нагрузкой | 5. Ресурсы и узкие места |
| 5 | Предложить **один или больше вариантов** решения проблемы, внятно объяснить **плюсы и минусы каждого** | развилка с ценой у каждого варианта | 4. Детали + БД |
| 6 | **Выбрать вариант и вернуться к пункту 4**, если время ещё есть; если заканчивается — перейти к следующему пункту | цикл, а не линейная лента | 4. Детали + БД |
| 7 | **Прикинуть размеры стораджей, количество серверов, пропускную способность сети** — и аккуратно это выписать | 3–4 расчёта с формулами | 5. Ресурсы и узкие места |
| + | **Бонус** (если осталось время): доп. фичи, внедрение ML, метрики продукта, эксперименты | — | Доп. вопросы / 6. Эксплуатация |

**Тайминг автора:** 5–10 минут на пункты 1–2 (требования), основное время — на пункты 3–6, ~5 минут на два последних (выбор и прикидка размеров). Это тот же профиль тайминга, что в `methodology.md` §1: быстро зафиксировать требования, долго — детали, обязательно оставить время на расчёты.

**Передача инициативы (важный практический нюанс):** «в самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с пункта 3 инициатива должна быть полностью у вас — и лучше её не отпускать до самого конца». Пункт 3 = «наше простое решение»; после него ведём мы. Совпадает с ролью кандидата из источника 1.

## 2. Что в этом плане нового по сравнению с источником 1

Источник 1 задаёт **слоёную** структуру (требования → API → блоки → детали → ресурсы → эксплуатация). Источник 4 задаёт **итеративный цикл** по тому же материалу. Три приёма, которые стоит унести:

1. **Старт с наивного односерверного решения.** Не рисовать сразу ДЦ, CDN и шардирование; сначала честная простая схема, «которая хоть как-то работает», и только потом рост. Хорошо снимает ступор первых минут и даёт интервьюеру видеть эволюцию мышления.
2. **Цикл «узкое место → 1+ вариантов → выбор → снова узкое место»** вместо линейного списка решений. Каждый виток — один найденный и устранённый SPOF; время кончилось — цикл заканчиваем на текущем шаге. Это ровно та схема, по которой в источнике 1 разобран URL shortener (read-нагрузка → KV-зеркало → согласованность → latency → падение сервера → …).
3. **Явный «бонусный» финал** (ML, продуктовые метрики, эксперименты). Для нашей секции «метрики продукта» — прямой мостик к metrics first источника 1 и к AI-направлению профиля: если остаётся время, это уместная тема для доп. вопросов.

## 3. Трейдоффы: формула и шаблоны

**Правило:** трейдоффы «нужно проговаривать, даже если кажутся очевидными». Фраза-каркас:

> «Мы добавили \<новый элемент\>, это решит \<такую-то проблему\>, но за это мы заплатим \<тем-то\>».

Шесть готовых шаблонов из статьи (`→` = «даёт» / «платим»):

| Что добавили | Даёт | Платим |
|--------------|------|--------|
| Любые новые компоненты / рост числа «запчастей» | нагрузку, скорость ответа | головную боль с поддержкой и деплоем |
| Шардирование | нагрузку и нехватку места | проблемы с перешардированием в будущем |
| Реплицированное хранилище | нагрузку и надёжность | протухшие значения (read/write реплики), противостояние доступности и консистентности |
| Кэш | нагрузку | протухшие значения и cache coherency |
| Собственное решение | легко менять и оптимизировать под себя | его придётся сперва написать |
| Существующее решение | оно уже существующее | в нём придётся разбираться |

В наших материалах эти заготовки разложены по темам: репликация и консистентность — `../knowledge-base.md` §5, §7; шардирование — §6; кэш — §4; «готовое вместо самописного» (KISS) — §3 и `../methodology.md` §3. Перенесено в чек-лист методички: `../methodology.md` §3, подблок «Шаблоны трейдоффов».

## 4. Числа: что важно по автору

Автор переформатировал «latency numbers every programmer should know» для запоминания (наша сжатая версия в том же духе — `../knowledge-base.md` §1.2). Ключевое, по статье:

1. **Знать временные расходы на чтение** из уровней процессорных кэшей, памяти, SSD, HDD и сети (полная лестница — KB §1.2).
2. **Помнить round trip внутри дата-центра и вокруг земного шара**, а также **минимальную задержку, которую человек ощущает как лаг, — ~100 мс**. Это число добавлено в KB §1.2: оно объясняет, почему SLO 150 мс из эталона Яндекса — «на грани комфорта», и почему round-trip через океан (150 мс) сам по себе съедает весь бюджет ответа.
3. **Уметь быстро конвертировать** байты в гигабайты, наносекунды в секунды — навык «вырабатывается сам собой в процессе практики» (KB §1.1, §1.3).

## 5. Методика практики

- **Доска и существующие сервисы:** «брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля» — рисовать схемы, прикидывать нагрузку и ресурсы, искать слабые места. Тот же формат, что в `../methodology.md` §6 (билет = сервис, 60 минут, доска).
- **Псевдосекции с живыми людьми** — «суперполезный опыт». Наш аналог — mock-сессия с ассистентом (`../methodology.md` §6.3): нейтральные ответы интервьюера, разбор только после раунда.
- **После практики — свериться с реальностью:** «лезть в интернет и искать, как это на самом деле сделано, а потом пробовать ещё раз». В нашем случае эталон уже собран в `../classic-designs.md`, а после раунда — self-review по рубрике.
- **10–20 раундов** с разными сервисами — и «наступает просветление»: повторяющиеся «запчасти» систем начинают быть отчётливо видны. Отсюда наша цель по раундам (§6 протокола) и приоритет билетов.

### «Запчасти»-паззлы: куда они у нас разложены

| Запчасть (по статье) | Примеры автора | Где у нас |
|---------------------|----------------|-----------|
| Поиск (с обновлением индекса в real-time) | — | KB §3 (инвертированный индекс); своего билета пока нет — кандидат в билет 5 |
| Файловое хранилище | GFS, Haystack | `classic-designs.md` §4 (медиа-хостинг), KB §3 (S3 + CDN) |
| Распределённое KV-хранилище | Cassandra, Dynamo | KB §3, §5, §6 |
| Message queue и pub-sub | Kafka | KB §8 |
| Лента новостей | Twitter, Instagram, Facebook | `classic-designs.md` §2 (+ эталон §1) |
| Чат, мессенджер, сервер онлайн-игры | WhatsApp, Telegram, Battle.net | `classic-designs.md` §3 |
| Стриминг, видео и аудио-чат | Skype, Twitch, YouTube | `classic-designs.md` §4 |

Вывод: наши четыре билета покрывают пять «запчастей» из семи; не закрыты поиск и игровой сервер — естественные кандидаты в дополнительные билеты, если после первого слота останется время.

## 6. Ресурсы и видео автора

Автор приводит пять категорий источников: **Grokking the System Design Interview** (решения не все оптимальны, но структура хорошая), **System Design Primer** (много полезного, но легко запутаться), **видео с конференций** (после пары десятков начинаешь видеть слабые места учебных решений; реальные системы иногда проще, иногда сложнее), **High Scalability**, и «самый важный ресурс — друзья и знакомые, которые расскажут, как устроены их системы».

Как это соотносится с нашим планом: Primer — уже законспектирован (источники 2–3 ✅); Grokking — пропускаем (платный, источник 1 тоже не рекомендует курсы); High Scalability — не берём до слота 18.09 (нет времени); «друзья» — mock-сессии с ассистентом; DDIA — источник 6.

Из списка видео автора **«Intro to Architecture and Systems Design Interviews» — это и есть материал 5 (Jackson Gabbard, TASK-45.9)**; остальные (Scalability, Four Distributed Systems Architectural Patterns, разборы Dropbox/Slack/Twitter/Reddit/Instagram/YouTube) — запас на фоновый режим после первой секции, не в интенсив.

## 7. Тактика: фон vs спринт

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

Применительно к нам: три варианта интенсива под слоты 18/21/22.09 уже расписаны в `../methodology.md` §5 (А/Б/В). После первой секции — перейти в фоновый режим: 1–2 материала в неделю из списка §6 плюс DDIA по карте KB §12.

## 8. Что забрали в наши материалы

| Материал статьи | Куда перенесён |
|-----------------|----------------|
| План из 7 пунктов, цикл «узкое место → варианты → выбор» | этот конспект §1–2; сверка с этапами `../methodology.md` §1–2 |
| Три приёма (наивное решение, цикл, бонусный финал) | раздел §2; применяем на тренировках |
| Фраза-каркас и 6 шаблонов трейдоффов | `../methodology.md` §3, подблок «Шаблоны трейдоффов»; связь с ошибкой №6 «решения без альтернатив» (§4) |
| ~100 мс — порог ощущаемого лага | `../knowledge-base.md` §1.2 (мнемоники) |
| Методика практики: доска, псевдосекции, 10–20 раундов, сверка с реальностью | `../methodology.md` §6, `../training/` |
| Запчасти-паззлы | `../classic-designs.md` (билеты), таблица §5 этого конспекта |
| Фоновый режим подготовки | план после первой секции (§7) |

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

- [`yandex-564132.md`](yandex-564132.md) — источник 1: официальный план секции и критерии оценки (интервьюер)
- [`../methodology.md`](../methodology.md) — фреймворк, тайминг, паттерны речи (шаблоны трейдоффов — §3), протокол тренировок §6
- [`../knowledge-base.md`](../knowledge-base.md) — числа (§1.2, включая порог ~100 мс), паттерны, карта DDIA
- [`../classic-designs.md`](../classic-designs.md) — эталонные разборы билетов («запчасти»)
- Источник: В. Комаров, «Как я научился проходить архитектурные секции» — [habr 516604](https://habr.com/ru/post/516604/)