---
title: Конспект материала 16 — А. Поломодов «Как подготовиться и пройти System Design Interview» (видео ArchDays 2022 + статья)
source_video: https://www.youtube.com/watch?v=jUbOm0B-eKQ
source_article: https://tellmeabout.tech/how-to-prepare-for-and-pass-the-system-design-interview-78b820589e8
author: Александр Поломодов (Tinkoff, архитектор мобильного банка, курирует системный дизайн в компании)
конспект: подготовлено 2026-09-17, TASK-45.20; статья (tellmeabout.tech) — текстовая расшифровка того же доклада, видео 1:04:03 дополнено 13 минутами живых вопросов, которых в статье нет
статус: RU-гайд №1 по формату со стороны интервьюера; фреймворк 7 этапов, подготовка по 6 блокам, 7 советов; сравнение с подходом Яндекса и перенос в methodology.md — §7–8
---

# Материал 16: Поломодов — как подготовиться и пройти System Design Interview

Автор — интервьюер по system design в Tinkoff (система мобильного банка; архитектурная секция идёт и инженерам, и всем техруководителям вплоть до CTO). Доклад ArchDays 2022; статья — полная расшифровка; видео сверх неё содержит 13 минут Q&A с ценными уточнениями (§6). Это взгляд *на подготовку под каждый этап секции* — в отличие от статьи Яндекса, где описан сам формат и что оценивают.

Ценность для нас: у Поломодова самое аккуратное на русском изложение **скоуп-дисциплины** (как вопросами срезать задачу до ядра), приоритизации архитектурных характеристик и разделения happy path / exceptional flows. Каркас секции (6 этапов Яндекса) при этом почти тот же — расхождения и что брать у него — §7.

---

## 1. Контекст: где живёт SDI в Tinkoff

- Проводится для инженеров, претендующих на **Senior**, и для всех технических руководителей (тимлид → CTO).
- Место в цепочке найма: **третья секция**, после алгоритмов и языка программирования.
- Задача секции — реальная и конкретная (пример дня доклада: бронирование номеров в отеле), час на интервью + полчаса на обсуждение результатов.
- В Tinkoff есть отдельный **troubleshooting-формат** для SRE-направления (система «горит», команда уехала на конференцию, джуну «дядя Вася» нужна помощь) — см. §6 Q&A.
- Матрица компетенций и профили: фидбэк по кандидату описывает **сильные стороны по этапам** («классно собирает требования, отлично проектирует API, но технологии и масштабирование слабо»), а не один балл — нанимающий менеджер смотрит профиль (подробнее §6).

## 2. Фреймворк интервью: 7 этапов (ядро конспекта)

Поломодов ссылается на 4-шаговый алгоритм Alex Xu (System Design Interview) и предлагает свой, более детальный фреймворк. Этапы:

| # | Этап | Что происходит | Кто говорит |
|---|------|----------------|-------------|
| 1 | **Постановка задачи** | Интервьюер даёт название задачи + контекст: основные функциональные и нефункциональные требования | больше интервьюер → затем замолкает |
| 2 | **Формализация** | Кандидат вопросами уточняет scope и фиксирует ключевые **архитектурные характеристики**: high availability, data consistency, high throughput, scalability, auditability; приоритизирует их между собой | кандидат |
| 3 | **Границы системы** | Публичное API для всех сценариев; способы интеграции с внешним миром | кандидат |
| 4 | **Итеративное проектирование** | Прорабатываются **happy path и exceptional flows**; компоненты «вырастают» из потока данных, нужного для сценариев | кандидат |
| 5 | **Концептуальная схема** | Готовая схема целиком: компоненты, модели данных, связи — всё консистентно в одном месте | кандидат |
| 6 | **Реальная схема + sizing** | Выбор конкретных технологий (Postgres vs MySQL, Kafka vs RabbitMQ…) и оценка, отмасштабируется ли система под нагрузку. Здесь видно знание современных решений | кандидат |
| 7 | **Дополнительные вопросы** | Опционально: расширение scope / ужесточение NFR (auditability, security, compliance…) — шанс сильного кандидата показать ширину | кандидат |

Пример из живой секции (отель): формализация → архитектурные характеристики (консистентность важнее всего: не продать больше броней, чем номеров, даже с учётом overbooking-задачи) → границы и API → потоки данных и компоненты (итеративно, с exceptional flows) → концептуальная схема с API и моделями данных → в финале конкретные технологии (БД, кэш, балансировщик) и что будет при росте нагрузки.

## 3. Подготовка: что уметь и что изучить по каждому блоку

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

### 3.1 Формализация (соответствует нашему этапу 1 «Требования»)

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

**Что изучить:**
- Функциональные требования: Use Cases из UML (actors + сценарии с happy path и exceptional flows), User Story («As a <role> I can <capability>, so that <benefit>»), Jobs to be Done (какую «работу» нанимает пользователь).
- NFR: **ATAM** в простом изложении из книги «Software Architecture for Busy Developers» (Eyskens): fit for purpose / fit for use, **sensitivity points** (влияют на один атрибут), **trade-off points** (влияют на несколько; жертвуем одним ради другого), risks / non-risks.
- Книга: Wiegers «Software Requirements. Third Edition» — «крутейшая» для понимания требований.

### 3.2 Границы системы (соответствует нашему этапу 2 «Потоки и API»)

**Что уметь:** выбирать правильный способ интеграции с внешним миром: **Files / Database / API / Messaging** (4 варианта из Hohpe, Enterprise Integration Patterns) с их плюсами/минусами; для API — подходы **REST (OpenAPI), RPC (gRPC, JSON-RPC), GraphQL, AsyncAPI** и уметь описывать контракты.

**Что изучить:** C4 Model — **System Context diagram** (границы и точки взаимодействия); сетевой слой, о котором «все забывают»: OSI, UDP/TCP/IP, DNS, HTTP 1/2/3, WebSockets; балансировщики (Nginx, HaProxy) и Service Mesh. Книги: Tanenbaum «Computer Networks», Hohpe «Enterprise Integration Patterns» (устарели конкретные решения, но концепции живут).

### 3.3 Основные потоки и компоненты (наш этап 3 «Крупноблочная схема»)

**Что уметь:** описывать **happy path** по компонентам; очерчивать **exceptional flows** (но не уходить в бесконечный анализ «что может пойти не так» — сначала спросить, глубоко ли это копаем); определять **read/write path** с учётом архитектурных характеристик.

**Что изучить:** C4 Container diagram; UML Sequence и Activity diagram (на интервью обычно не рисуют — долго, но понимание помогает мыслить); для кругозора: IDEF0, DFD, BPMN; по балансу read/write path — Kleppmann (DDIA) с его разбором ленты соцсети (торгуем временем записи против скорости чтения).

### 3.4 Концептуальная схема (наш этап 4 «Детали + БД»)

**Что уметь:** делить систему на **stateless/stateful** компоненты (stateless легко масштабируются; париться надо только про stateful — где состояние хранится); проектировать модели данных под сценарии (см. кейс отеля §5); выбирать класс хранилища.

**Что изучить:** DDD-стратегия — subdomains, ubiquitous language, bounded contexts (Khononov «Learning DDD»); ER-диаграммы / UML Class Diagram; **12-Factor App** (манифест всё ещё актуален для cloud-native); «K8s Patterns» (Ibryam) — как разработчик приложений использует Kubernetes (масштабирование, конфигурация); «Software Architecture: The Hard Parts» (Ford et al.) — зоны ответственности компонентов и работа с данными.

### 3.5 Реальная схема и архитектурные характеристики (наш этап 5 «Ресурсы» + часть 6 «Эксплуатация»)

**Что уметь:** выбирать конкретного представителя класса (реляционные: Postgres/MySQL/Oracle; очереди: ActiveMQ/RabbitMQ/Kafka/Pulsar) — знать гарантии и сложность эксплуатации; мыслить **failure domains** (сервис → машина → зона доступности → ДЦ); учитывать **day-2 operations**: логирование, мониторинг, миграции, развитие (чтобы не «жить больно» потом).

**Что изучить:** технологии — **трогать руками**: документация → поднять в тестовом окружении/облаке → поиграть с основными сценариями → managed-версии; собрать представление «rps per cpu» — на какой диапазон нагрузок рассчитана система, и единицу масштабирования на стандартной вмке (ядра/память/диск); SRE: **Building Secure and Reliable Systems** (читать обязательно: первая половина — проектировать надёжность/безопасность сразу, добавить постфактум «на порядок дороже»), SRE Book, SRE Workbook. В Q&A добавил: **Jepsen-тесты** — как проверять заявленные гарантии под нагрузкой/дрифтом часов.

### 3.6 Масштабирование под нагрузку (часть нашего этапа 5 и 6)

**Что уметь:**
- Stateless: оркестратор (K8s) — вертикально (VPA) и горизонтально (HPA); метрики: per-pod resource (CPU), per-pod custom, object/external metrics (глубина очереди для воркер-подов).
- Stateful: **масштабировать чтения** — кэш (вопрос консистентности и инвалидации) или репликация с чтением со secondary (ослабление консистентности); **масштабировать записи** — partitioning/sharding (обязательно знать паттерн доступа к данным; ключ шардирования должен присутствовать в запросах — в отеле это hotel id).

**Что изучить:** DDIA (Kleppmann) — старт; далее Tanenbaum «Distributed Systems», Petrov «Database Internals», Ibryam «K8s Patterns»; плюс обязательный **нагрузочный тест своими руками**, чтобы понимать единицу масштабирования.

## 4. Кейс из живой секции: бронирование отеля (примеры от интервьюера)

Поломодов разбирал в день доклада секцию коллеги (задача «система бронирования номеров в отеле») — по его словам, «почти идеальную», с 1–2 помарками. Что отсюда полезно:

- **Overbooking как задание**: отель может продать больше броней, чем номеров (наплыв гостей) → нужен инвентарь **по типам комнат на каждую дату**: сколько доступно, сколько забронировано. Модель данных — не про «отели и комнаты» (это просто), а про сценарий «какие типажи комнат доступны на интервал».
- **Промах коллеги №1 (модель данных):** чётко расписал сценарий «забукать номер», но не предусмотрел в модели поля для сценария «получить доступные комнаты на интервал» — интервьюеру хватило одного наводящего вопроса «а как мы эти данные получим?».
- **Промах №2 / сетевая глубина:** пропало сетевое соединение при брони — клиент не получил ответ и повторит запрос → **двойная бронь и двойное списание** → нужна **идемпотентность** запросов. Урок: про сетевой слой в happy path можно забыть, но в exceptional flows он обязателен.
- **Скоуп решается вопросами:** админка (добавление отелей/номеров) — «нужный, но скучный» supporting subdomain → срезали; платёжный шлюз — «готовое решение или система другой команды» → вынесли за границы.
- **Ключ шардирования:** hotel id — во всех запросах, значит, хороший ключ для шардирования.

## 5. Семь советов для самого интервью (короткий путь «как проявить себя»)

1. **Помнить о времени.** Час — не закапываться в детали, контролировать тайминг и двигаться по плану. Плохо: 15–20 минут на формализацию, потом ничего не успел.
2. **Не начинать проектировать сразу.** Сначала понять задачу; вопросы по условиям задать до проектирования — иначе «начнёте не ту задачу». Особенно в незнакомом домене.
3. **Делиться размышлениями.** Секция про то, *как вы решаете*; молча рисовать и раз в 5 минут отчитываться — интервьюер не увидит глубины. Интерактивность решает: он войдёт в обсуждение как коллега.
4. **Проявлять самостоятельность.** Интервью открытое: строй гипотезы и предлагай сам; если интервьюеру приходится вести кандидата — «очков не добавит».
5. **Реагировать на наводящие вопросы и уточнения.** Они не просто так: кандидат где-то буксует или недокрутил. Отработать хинт (см. §6.3) лучше, чем «обсудим потом» и никогда не вернуться.
6. **Говорить уверенно о том, что знаешь** — а не бросаться словами, о которых смутно слышал: интервьюер докопается, и придётся краснеть.
7. **Подготовить вопросы к интервьюеру** на остаток времени (про задачу, компанию, про «странные места» в секции, рекомендации по чтению) — показывает живой интерес; в Tinkoff на интересные вопросы готовы общаться ещё полчаса.

## 6. Находки из Q&A (в статье их нет — только в видео, 46:46–1:04)

- **Как резать скоуп:** прямо спрашивать «это в нашей задаче?», «это готовое решение / сервис соседней команды / не в первой версии?» — и после 2–3 вопросов остаются буквально 3 сценария, из которых часто **только один реально сложный** — его и прорабатывать; остальные «носки», нужные чтобы сценарий работал.
- **«Обсудим потом» — анти-паттерн.** Примета хорошего кандидата: на подсказке сам закрывает дыру («а, да, понял»). Примета плохого: «вернёмся к этому потом» — и никогда не возвращается. Такие вещи интервьюер запоминает.
- **О подсказках:** хинт дают, когда кандидат явно буксует — «90% правильного ответа — это правильно заданный вопрос», и хорошая подсказка сама по себе почти ничего не раскрывает при правильной реакции.
- **Абстрактные задачи («спроектируй библиотеку в большом городе»)**: пробовали — инженерам сложно переключиться в такой режим; пришли к **скоупнутой задаче с основными требованиями**, дальше кандидат сам допытывает. (У учёных-архитекторов в статье Яндекса та же логика — реальную систему берут за основу.)
- **Компетенции и оценка:** в Tinkoff фидбэк содержит профиль сильных сторон по этапам, а не средний балл; нанимающий менеджер смотрит, закрывает ли кандидат дыру команды (штука «общаться с бизнесом» vs «внутренняя техника»). Баллами по секции без контекста профиля пользоваться нельзя.
- **Зачем архитекторам алгоритмы:** не для «погонять задачки», а чтобы раскладывать данные так, чтобы их удобно было выбирать под нагрузкой (история автора: соцсеть на нормализованной реляционной БД «сложилась» под трафиком).
- **IC-трек в Tinkoff**: есть путь индивидуальных контрибьюторов (staff/principal) с подачей заявки артефактами и отзывами коллег; девиз уровня — по-амазоновски «design → implement → operate» (спроектировать, закодить, обслужить, чтобы не развалилась).
- **SRE troubleshooting-interview**: система уже есть, она «горит», команда на конференции — как чинить; показывает работу с инцидентами лучше system design; для топ-инженеров комбинация обоих форматов ценнее.

## 7. Отличия от подхода Яндекса (сравнение с `yandex-564132.md` и нашей методичкой)

Каркасы совпадают (требования → потоки/API → схема → детали → ресурсы → эксплуатация), но есть системные различия:

| Аспект | Поломодов (Tinkoff) | Статья Яндекса → наша методичка `methodology.md` |
|---|---|---|
| Число этапов | **7** (формализация, границы, проектирование, концептуальная схема, реальная схема+sizing, доп. вопросы) | **6** (требования, потоки+API, крупноблочная, детали+БД, ресурсы, эксплуатация) + доп. блок |
| Скоуп-дисциплина | Сформулирована жёстко и отдельно: минимализм, вопросы «это наша система или уже есть?», часто один сложный сценарий | Есть неявно («гипотезы при нехватке данных», «не усложняйте»), но как техника не разбирается |
| Архитектурные характеристики | Отдельный этап с инструментом приоритизации (ATAM: sensitivity/trade-off points) и явным списком (HA, consistency, throughput, scalability, auditability) | Внутри «формализации требований»: время ответа, доступность, согласованность — без отдельного инструмента |
| Exceptional flows | Явный этаж фреймворка (happy path + exceptional flows), отдельный шаг интервью | Нет прямой формулировки; отказоустойчивость проверяется на этапе эксплуатации («переживание отказа») |
| Sizing и числа | Мягко: «обсудить sizing с учётом выбора технологий», без обязательного back-of-envelope; расчёты не в ядре фреймворка | Жёстко: этап 5 «оценка ресурсов» с latency numbers, CPU/RAM/disk/network, поиском узких мест — обязательный |
| Эксплуатация | Упоминается как day-2 operations в блоке реальной схемы (логи/мониторинг/миграции) + failure domains | Отдельный обязательный этап 6: топология, отказы по каждому узлу, metrics first, поведение при нагрузке в разы |
| Контроль времени кандидатом | Прямой совет №1 («помнить о времени», не закапываться) | «План простой — запомнить и придерживаться»; тайминг задаёт наша методичка |
| Что даёт сверх каркаса | Подготовительный «длинный путь» (книги по каждому блоку), скоуп-вопросы, кейсы от интервьюера, Q&A про подсказки | Эталонный разбор URL shortener с числами, критерии оценки, metrics first, «взгляд в 4 измерениях» |

**Вывод для нашей секции (Yandex Codenv).** Основной каркас — статья Яндекса и методичка (§1–2): этот формат мы и встретим, а его эталон URL shortener прогнан в `classic-designs.md`. Из Поломодова берём три вещи как *надстройку* над этим каркасом: (1) скоуп-вопросы на этапе требований, (2) приоритизацию архитектурных характеристик с проговариванием трейдоффов, (3) поведение: разделять размышления, самостоятельно вести, ловить хинты как сигнал «где-то буксуешь».

## 8. Что перенести в методичку (TASK-45.2) — предложения

1. **§1/§2, этап «Требования»:** добавить скоуп-вопросы-минималиста («это наша система, готовое решение или сервис соседней команды?», «что не в первой версии?») и правило «часто из 3 оставшихся сценариев сложен один — найти его и копать туда».
2. **§2, этап «Требования»:** явный список архитектурных характеристик (HA, consistency, throughput, scalability, auditability) + проговаривание трейдоффа: «какой характеристикой жертвуем ради какой» (ATAM trade-off points — без терминов).
3. **§2, этап «Потоки и API»:** явно разделять happy path и exceptional flows; на exceptional-flow спрашивать «это копаем глубоко или очерчиваем?».
4. **§3, чек-лист речевых паттернов:** фразы «предлагаю вынести за скоуп, если время останется — вернёмся», «ключ шардирования есть во всех запросах?», «компонент stateless — масштабируется тривиально; состояние вот здесь».
5. **§4, топ ошибок:** добавить «обсудим потом» без возврата (анти-паттерн, пример Поломодова) и «молча рисовать, отчитываться раз в 5 минут» (совпадение с Gabbard §3.1 — усилить ссылкой).
6. **§3, правила поведения:** блок «реагировать на наводящие вопросы» — хинт дают, когда буксуешь; правильная реакция — закрыть дыру сразу («а, да, понял»), а не «вернёмся».
7. **Не переносить:** «длинный путь» подготовки Поломодова (книги по блокам) — это курс на месяцы, для слотов 18/21/22.09 нерелевантен; детали Tinkoff-процесса найма.

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

- `../methodology.md` §1–4 — каркас и тайминг секции (TASK-45.2) — цели переноса в §8
- `yandex-564132.md` — статья Яндекса, эталон формата (TASK-45.5) — сравнение в §7
- `jackson-gabbard-ep06.md` — правила поведения на секции (TASK-45.9) — пересечение с §5 советами Поломодова
- `learn-system-design-index.md` — индекс подборки (TASK-45.12), строка материала 16