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.

Тайминг автора: 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. Трейдоффы: формула и шаблоны

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

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

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

В наших материалах эти заготовки разложены по темам: репликация и консистентность — ../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 протокола) и приоритет билетов.

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

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

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. Что забрали в наши материалы

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

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