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) и предлагает свой, более детальный фреймворк. Этапы:

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

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

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

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

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

Что изучить: - Функциональные требования: Use Cases из UML (actors + сценарии с happy path и exceptional flows), User Story («As a I can , so that »), 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 → схема → детали → ресурсы → эксплуатация), но есть системные различия:

Вывод для нашей секции (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