title: Конспект материала 23 — «Интервью по System Design» (Поломодов, Tinkoff): запись реального интервью source_video: https://www.youtube.com/watch?v=Wh5Ya6UFG1k author: интервьюер — Александр Поломодов (Tinkoff, архитектура мобильного банка, курирует SDI); кандидат — Даниил, коллега Поломодова (архитектор направления авторизации, сам проводит дизайн-интервью) конспект: подготовлено 2026-09-17, TASK-45.27; ArchDays 2022, 1:26:41; по автотранскрипту (имена/термины восстановлены по контексту: «позглись» = Postgres, «ткань месяц Q» = Kafka, «лот-бокс» = outbox и т.п.); запись начинается сразу с уточнения функциональных требований — интро обрезано статус: единственная на русском запись, где интервьюер уровня Т-сети проводит секцию вживую и потом сам разбирает её по шагам; задача — бронирование отелей, та же, что приводится как пример в гайде автора (материал 16); тайминг ~60 мин интервью + 26 мин разбор и Q&A зала

Материал 23: Интервью по System Design — Поломодов × Даниил (запись реальной секции)

Живая секция на флипчарте с конференции ArchDays 2022: Поломодов (интервьюер) даёт кандидату задачу «система бронирования отелей», час проектирования, затем развёрнутый фидбэк и Q&A зала. Это видеоверсия того самого формата Tinkoff, который автор описал в докладе «Как подготовиться и пройти System Design Interview» (материал 16) — и даже задача та же («бронирование номеров в отеле» как пример дня доклада). Для нас это эталон «как выглядит сильное исполнение от первой минуты до вердикта»: кандидат проходит срезы (методичность, границы, контракты), на которых в моках karpov.courses (материал 22) люди сыпались, и получает разбор двух настоящих пробелов — обе про оценку объёмов данных.

1. Формат и участники

• Хронометраж: ~60 мин интервью (запись стартует уже с функциональных требований) → разбор интервьюера ~8 мин → Q&A зала ~18 мин.
• Задача: система бронирования отелей (гость бронирует номер; менеджеры управляют отелями/номерами; оплата — внешний провайдер). Поиск/фильтры/карты, регистрация отелей, аналитика — осознанно вынесены за скобки.
• Кандидат — не студент: архитектор авторизации в Tinkoff, сам водит дизайн-интервью, «готовился и переживал». Это калибрует планку: Strong-исполнение показал человек, который сидит по другую сторону доски.
• Задача в банке Tinkoff новая — «давал всего несколько раз»; останется учебной.

2. Ход секции (по таймкодам)

[00:00–12:00] Границы + функциональные требования. Кандидат объявляет подход («мне нравится C4, начнём с границ системы») и рисует участников: гость, менеджеры, внешний платёжный провайдер. Скоуп-вопросы решаются на лету: юзер-профайлинг/чат — «есть, но не наша система»; регистрация отелей — «вернёмся, если останется время» (интервьюер: админ-панель он сам убрал из базового скоупа). Функциональные требования сразу фиксирует REST-контрактами: GET /hotels, GET /hotels/{id}/roomtypes/{id}, POST /reservations (payload: userId, startDate/endDate, roomTypeId, hotelId, количество номеров — «5 одноместных для коллег одним бронированием»), DELETE (оговорка: в реальности soft delete), PATCH, отдельный POST оплаты. Ключевая доменная находка: бронируется roomType, а не комната — «сколько я пользуюсь букингами — это всё-таки roomType»; вложенные ресурсы «как в REST-спецификации».

[12:12–17:55] NFR + оценка нагрузки. Интервьюер даёт вводные: 20 000 отелей в РФ, номерной фонд ~1 млн (статистика 2021), заполнение 60%, среднее пребывание 3 дня, воронка «100% смотрят отель → 10% играют с датами → 1% бронирует». Расчёт кандидата: 1M × 0.6 / 3 дня = 200K броней/день → среднее ~2 rps записи («наши любимые константы» — 86 400), с праздничными всплесками закладываем ~50 rps. Просмотры: 200K × 100 (воронка) = 20M/день → в пиках ~5K rps чтения. Вывод-водораздел: чтение на 2–3 порядка тяжелее записи → кэш и реплики.

[17:55–29:00] Контейнерная диаграмма. API Gateway (auth + балансировка: «банальный nginx round-robin»), Hotel & Room API + Booking API как два сервиса («точно сервисная архитектура, не говорю про микросервисную»), перед Hotel API — кэш (5000 rps), БД master + слейвы на чтение с синхронизацией. Выбор хранилища: отели/комнаты — «реляционная не обязательна, но Postgres с констрейнтами проще», booking — обязательно транзакционная целостность → реляционная (про распределённые с транзакциями — Spanner/CockroachDB — вспомнил, но честно: не работал, «в наших реалиях» Postgres). Оплата — внешний провайдер; взаимодействие с ним через outbox (в транскрипте «лот-бокс»): локальная таблица попыток со статусом pending, retry до подтверждения.

[29:04–39:00] Overbooking + доменная модель. Кандидат сам ловит потерянное требование: «я забыл очень важный функциональный requirement — overbooking». Модель: Reservation (userId, roomTypeId, даты, цена, статус: pending → оплачен / отменён), RoomType (base price, total count, overbooking-мультипликатор: для стандартных комнат больше, для пентхаусов меньше — «цена ошибки: переселять в более дорогое жильё»), Room (конкретный номер со статусами клининг/ремонт — для ресепшена). Динамическое ценообразование (вопрос интервьюера «как в авиакомпаниях») — множитель от заполнения, «делать полноценную систему — отдельная задача, есть внешний сервис». Синхронизация справочника в booking-сервис: менеджмент пишет в БД + событие в Kafka → RoomType Sync Job обновляет локальную копию (денормализация, чтобы не ходить в чужой сервис).

[39:00–49:50] Конкуренция за бронь (ядро задачи). ACID и уровни изоляции: грязное/неповторяющееся чтение, фантомы, serializable («самый крутой режим, но при пиках база начнёт тормозить») → выбор Repeatable Read. Сценарий брони: SELECT свободных roomType'ов по диапазону дат → INSERT reservation + UPDATE счётчика — в одной транзакции; при конфликте (другая транзакция закоммитилась раньше) — ошибка сериализации → rollback → retry со свежими данными (число ретраев — в конфиге). Классифицирует выбор как оптимистичные блокировки (нет «супер-конкуренции» на одну запись; пессимистичные — SELECT FOR UPDATE — блокируют всех). В диалоге всплывает производственная история (автор по транскрипту неочевиден): в MySQL при некоторых уровнях изоляции Repeatable Read работает «не так с журналом» — на одном продукте пришлось делать блокировки на стороне приложения и строить реплицированную систему.

[49:50–55:25] Шардирование. «Если пойдём захватывать рынок и нагрузка вырастет на 1–2 порядка»: распределённые БД со строгой консистентностью (Spanner — «проприетарный, везде strict serializability»; CockroachDB — «слышал, не трогал»; YDB — «не ресёрчил, ничего не скажу» — честность границы знаний). Классика: консистентное хеширование — кольцо, виртуальные шарды (3 шарда × 10 = 30 точек), добавление ноды перекладывает данные «по часовой стрелке». Ключ шарда — hotelId: даты не подходят (стыки годов/месяцев — тормоза на выборках), «гиганты типа Radisson не страшно» — отелей тысячи, перекос терпим.

[55:25–60:10] Финальный вопрос — идемпотентность. Интервьюер из личного кейса (дважды купленные билеты в Сочи: ответ не дошёл → повтор → двойная покупка): как защититься? Решение в диалоге: клиент генерит idempotency key (UUID v4, коллизий нет), состояние формы не сбрасывается до ответа; «в мобильном банке у нас это из коробки».

3. Вопросы интервьюера (полный каталог по назначению)

Паттерн: вопросы не «проверяют наизусть», а подталкивают к следующему слою — почти каждый сдвигает фокус секции. Три скоуп-вопроса подряд в начале — обученный приём: кандидат должен показать, что умеет говорить «не наша система».

4. Сильные ходы кандидата (из фидбэка интервьюера)

1. Методичность и пошаговость — главная похвала: «очень системно, очень качественно… переход от шага к шагу». Не домен, не технологии — дисциплина хода.
2. Границы и контракты сразу: зафиксировал игроков, затем немедленно REST-контракты — «очистил то, что входит в систему»; каждый раз уточнял, входит ли кусок в скоуп → «не взял на себя больше работы, чем требуется» (у других кандидатов бывает «слишком расширяют»).
3. Правильная глубина на второстепенном: отели/комнаты прошёл быстро (действительно простая часть), сконцентрировался на букинге — «основной сложности».
4. Сам поднял два из трёх «запасных» вопросов интервьюера: overbooking вспомнил сам; динамическое ценообразование назвал и объяснил сам. «Даниил хлеб забрал — часть вопросов просто сам сказал в ходе проектирования».
5. Честность границ знаний: Spanner/CockroachDB/YDB — «не работал, не ресёрчил, ничего не скажу»; это не минус, а нормальная подача.
6. Останавливаться на нужном уровне: динамическое ценообразование — объяснил суть и явно сказал «полноценная система — отдельная задача».

5. Слабые места и пробелы (из фидбэка + наблюдения)

1. Объёмы данных не посчитаны — «не сильно закинули в объёмы»: сколько строк букингов за N лет; в timeline-схеме (roomType × дата) записей «достаточно много и они часто меняются и запрашиваются». Наш пересчёт для чувствительности: 20K отелей × ~5 типов × 365 дней ≈ 36M строк/год — число, которое меняет тон разговора о шардах.
2. Затык в доменной модели на датах: написал таблицы, но «потерял часть, связанную с датами» — как выбирать доступность на конкретную дату. Интервьюер: «когда думают про сложность букинга, думают про то, как сложно забукать; а какие комнаты доступны — как будто уже знаем». Лечится вопросом самому себе: «как я найду свободные комнаты?» — ответ сам вытащил бы timeline-таблицу.
3. Наблюдения наши (в фидбэке не прозвучали): NFR не проговаривались как явная приоритизация (consistency > availability для брони прошло по умолчанию); latency-требований не было вовсе; единицы масштабирования («сколько держит одна нода API») не оценивались.

6. Техническое ядро (вынести в KB-практику)

• Timeline-схема доступности: строка на пару (roomType, дата); бронь на 3 дня = чтение/апдейт 3 строк. SELECT … WHERE date BETWEEN start AND end → INSERT reservation + UPDATE booked-счётчика в одной транзакции.
• Оптимистичные vs пессимистичные блокировки: выбор через оценку конкуренции на запись; ретраи после ошибки сериализации, лимит — конфиг.
• Шардирование по hotelId + консистентное хеширование с виртуальными шардами (×10 точек) — типовая пара для «справочник + факты» в бронировании.
• Идемпотентность через клиентский UUID v4 — прямой ответ на «двойное списание»; у Tinkoff в мобильном банке — из коробки.
• Картинки отелей — из CDN/S3 (замечание интервьюера в фидбэке): «частая отдача картинок» — хранить ссылки, раздавать из гео-распределённой сети, «но не критично для таких интервью».
• Outbox для внешнего провайдера оплаты: локальная таблица попыток (pending), retry, статус.

7. Q&A зала (что ещё сказал интервьюер о формате)

• Sequence-диаграммы на интервью не рисуют — «не хватает времени»; достаточно текстового порядка вызовов на компонентной диаграмме (ответ на претензию «разбирали БД без Flow»).
• Последние ~5 минут — вопросы кандидата интервьюеру: «несправедливо, когда час задаёшь вопросы ты».
• У каждой задачи — 3–6 запасных вопросов; здесь: идемпотентность (задан), динамическое ценообразование (закрыт самим кандидатом), окно оплаты 10–15 мин (успели по ходу).
• Изменение требований по ходу — инструмент интервьюера: «если кандидат слишком хорошо решает — подкидываем вырезанную сложность» и смотрим, как модифицирует систему. Плюс trouble-shooting: «что будет, если база упадёт, а событие в очередь уйдёт?»
• В запросах SQL расписывать всё не нужно — «достаточно, чтобы понял, о чём речь» (экономия времени).
• Вердикт: «по совокупности — выбил [ уровень senior ] по нашей внутренней градации»; оговорка: методичность связана с тем, что кандидат сам проводит SDI. Задача остаётся в банке.

8. Перенос на нашу подготовку (слоты 21–22.09)

• Смотреть целиком перед слотом 22.09 (в индексе — P2, 60 мин): это единственное видео, где виден полный проход сильного кандидата по русскоязычной секции + разбор. Оптимально — после lsd-karpov-mocks.md (контраст «тонущих» и «сильного»).
• Скрипт первых 10 минут подтверждён образцово: C4-границы → участники → REST-контракты → NFR/числа. Ровно наш methodology.md §2–3 — расхождений нет, есть подтверждение.
• Три личные прививки от пробелов кандидата: (1) посчитать объём хранения/строк сразу после RPS — «сколько записей в год»; (2) в доменной модели спросить себя «как я найду свободные X по датам?» до рисования таблиц; (3) проговорить приоритет NFR одним предложением (consistency для денег/броней).
• Отработка вопросов из §3 — готовые реплики: «это входит в нашу систему или есть из коробки?», «есть понимание RPS или прикину?» (последний — сам кандидат, §2).
• Связанные материалы: lsd-polomodov-guide.md (М16 — тот же автор, тот же домен отеля: фреймворк 7 этапов в теории), lsd-karpov-mocks.md (М22 — контраст уровня), ../methodology.md §2–3 (каркас совпадает), ../knowledge-base.md §1 (числа: 86 400, воронка 100/10/1), ../classic-designs.md §2 (лента — та же механика «строка на дату/юзера»).