title: Конспект материала 22 — karpov.courses «Пробные собеседования по System Design» (плейлист) source_playlist: https://www.youtube.com/playlist?list=PLBRXq5LaddfzDBjg6soIwJJA2klXXs6ni author: интервьюер — Егор Бабушкин (ex-Google/Ozon, автор книги «Системный дизайн. Подготовка к сложному интервью», mok.interview); кандидаты — студенты/выпускники karpov.courses конспект: подготовлено 2026-09-18, TASK-45.26; из 20 видео плейлиста к SD относятся 5 (Вып.1–4 + отдельный 2-часовой стрим); конспект построен на расшифровках автосубтитров (качество среднее — имена/числа сверены по контексту) статус: единственный на русском источник, где видно, как звучит секция SD изнутри от первой минуты до фидбэка; Вып.2 (Instagram) — прямая репетиция темы этапа 2 (лента соцсети); маппинг на наш формат — §7

Материал 22: Пробные собеседования karpov.courses — как выглядит секция SD изнутри

Плейлист записей реальных мок-интервью: интервьюер ставит задачу, кандидат проектирует вслух у доски ~45–90 минут, в конце — разбор ошибок. Для нас это «аудио-эталон» русскоязычной секции: последовательность шагов, темп, где кандидаты тонут и что за это говорит интервьюер. Конспект охватывает топ-3 видео детально (§3–5), остальные два — кратко (§6); сводка типовых ошибок и перенос на нашу подготовку — §7–8.

1. Формат мока у Бабушкина (сквозной по всем выпускам)

• Хронометраж выпуска: ~1 час (Вып.1–4: 47–58 мин); отдельный стрим — 2 часа. Структура: 2–5 мин интро-вопросы про бэкграунд → постановка задачи → кандидат солирует → дебриф 5–15 мин.
• Ключевая цитата о формате (Вып.1): «я замолкаю на 40 минут — ты солируешь». Интервьюер почти не помогает, вмешивается только когда кандидат буксует или уходит в оверинжиниринг.
• Вопросы интервьюера — трёх типов: (а) уточнить скоуп («а сколько фото в день?»), (б) проверить осознанность («зачем тебе отдельная БД — это же витрина»), (в) сместить фокус («давай без выбора газа через приложение»).
• Двухчасовой стрим идёт вживую с чатом: зрители подкидывают технологии (Greenplum, ClickHouse, Spanner, Vitess), интервьюер проверяет их и сам признаёт пробелы — редкая возможность видеть, как интервьюер рассуждает о выборе БД в реальном времени.
• Оценка в конце — не балл, а вердикт уровня: «пройдёшь / не пройдёшь на такой-то уровень», с главной оговоркой «пройдёшь, если не будешь закапывать себя» (§5).

2. Почему именно эти три видео

Вып.3 (Uber) и Вып.4 (web crawler) — §6: паттерны оттуда уже покрыты нашим KB (graph+heap → KB §9; crawler-квоты/politeness — стандартный блок Alex Xu).

3. Вып.1 — URL shortener: как выглядит «правильный» каркас

Ход интервью. Требования: глобальный сокращатель, редирект; кандидат уточняет read:write (читают в 100–1000 раз чаще) → base64-кодирование, подбор длины ключа (10 символов → 8 → 48 бит, «минус 20 % места») → на лету: MD5-хэш от URL, обрезка до 48 бит → коллизии («урезанный хэш многократно повышает риск») → переход к пулу предгенерированных ключей: генератор выдаёт пачками, лок в памяти, выдали — вычеркнули.

Расчёты, которые двигали дизайн (главный урок выпуска): 10⁸ ссылок × 6 байт ≈ 5 ГБ — «можно на макбуке в оперативке» → значит кэшируем вообще всё; миллион ссылок/день ≈ 10 rps записи; ×1000 чтения ≈ 1000 rps — обычный сервер тянет, «проблем нет».

Итоговая схема (рисует интервьюер в дебрифе): LB (несколько) → разделение read/write-запросов → кэш → если мимо — key-value БД (Dynamo/Cassandra — реляционная не нужна, доступ только по ключу) + сервис key-generator с пулом ключей и локами. Партиционирование: данных мало — можно реплицировать всё везде.

Ошибки кандидата: не спросил latency — а интервьюер сам подсказал: «мы хотим 200 мс; пользователь из Аргентины не должен ходить на сервер в Европе» (скорость света как ограничение → гео-распределение); арифметика вслух с ошибками (порядок величин терялся, интервьюер исправлял).

Формула из дебрифа (цитировать почти дословно): «первое, что ты спрашиваешь — CAP-ограничения, буквально одну секунду; потом сразу производишь расчёты — QPS, память; расчёты влияют на дизайн». Для shortener: согласованность не критична (ссылка может вести «в одно и то же место» с лёгкой задержкой), доступность и скорость — важнее.

4. Вып.2 — Instagram: прямая репетиция нашего этапа 2

Ход интервью. Уточнение требований: читаем ленту vs постим фото (read >> write), глубина скролла; сущности: user, follows (user→user), photos. Back-of-envelope: 3×10⁹ фото/день × 500 KB = 1,5 PB/день — на этом месте у кандидата многочасовой по меркам интервью ступор: паузы, потеря порядка величин, интервьюер тянет за язык («сколько это гигабайт? делим на 10⁶…»).

Дальше: таблицы и атрибуты, кэш перед хранилищем, типы БД под сущности (метаданные фото — key-value, граф follows — можно реляционную).

Фидбэк — 7-шаговый алгоритм (интервьюер проговаривает как чек-лист, «теперь ты знаешь, что вначале делаешь»): 1. собрать требования; 2. списать нагрузку: RPS, хранилище, связи; 3. сколько нужно машин; 4. нарисовать общую схему на одной машине; 5. как обеспечить доступность; 6. главный вопрос — партиционирование: по юзеру, но: hot keys — «Скала выложил фото → 200 млн стучатся к одной фотке → сервер ляжет»; лечится отдельной балансировкой популярного контента, replication factor не 3, а 10–20, кэширование CDN; 7. скорости: запись диска ~100 МБ/с, RAID, сколько connections держит сервер, poll vs long-poll для обновления ленты.

Вердикт: «как только ты вышел из ступора, пошло плюс-минус нормально» — то есть проигрыш был не в знаниях, а в стартовом скрипте: первые 10 минут решают, зацепишься ли за каркас.

5. Стрим 2 ч — АЗС-сеть: полный цикл и «не закапывай себя»

Задача: система для сети АЗС (25 000 точек): продажи топлива, мультивалютность, быстрое изменение цены, мониторинг остатков в резервуарах, HA + согласованность денег.

Ход. Кандидат (самоучка, «практики нет, голая теория — буду изобретать из головы») идёт от бизнес-требований: сущности → сервисы payments / payments-in-store / мониторинг газа → внешние банки (outsourced, со стрелкой подтверждения туда-обратно) → high-level → component design. Расчёты: 1000 транзакций/сутки × 25K точек = 25M/день ≈ 300 rps средних / пики ×30 → ~10K rps; WhatsApp-анекдот интервьюера про миллионы соединений на одной машине. В конце — сжатие данных: литры в 2 байта (2¹⁶ хватает), цена — фикс. точность 2 знака.

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

Выбор БД (дебриф с чатом): ACID нужен и там и там; Greenplum vs Spanner — «не могу принять, что это одно и то же»: Spanner — глобально-распределённый реляционный (TrueTime), Greenplum — колоночный аналитический MPP; ClickHouse защищён интервьюером («один из немногих российских продуктов, реально используемых за рубежом»); вывод: под глобальный распределённый SQL смотреть Spanner/Vitess, под аналитику — колоночные.

Вердикт: «пройдёшь, если не будешь закапывать себя» + упоминание, что за мультивалютность и консистентность денег кандидат балл поднял. Кандидат позже прошёл собеседование в Google.

6. Кратко: Вып.3 (Uber) и Вып.4 (web crawler)

• Вып.3 Uber («самая сложная задача плейлиста»): matching водитель-пассажир в реальном времени, гео-индексы, граф + heap для ближайших машин, Kafka как поток событий местоположений. Основная сложность — частые обновления координат (высокочастотный write) против редких запросов.
• Вып.4 web crawler: краулер всего интернета (15K машин, бюджет $10–15 млрд на инфраструктуру): frontier URL-ов, очереди, роботс/политика частоты хождения (politeness), дедупликация контента, приоритизация свежести.

7. Типовые ошибки кандидатов (сводка по всем мокам)

1. Ступор на старте — самый дорогой грех: нет скрипта первых 5–10 минут (требования → оценка нагрузки). Лечится жёстким порядком из дебрифа Вып.2 (§4).
2. Арифметика теряет порядок величин — единицы, деления на 10³/10⁶, «сколько это гигабайт»: интервьюер исправляет, но это фиксируется как слабость. У нас — complexity-cheat-sheet.md (алгомыски) + KB §1 (числа): тренировать до автоматизма.
3. Не спросить нефункциональные требования: latency (200 мс → гео), CAP-приоритеты, R/W-соотношение. Правило из Вып.1: CAP-вопрос задаётся «буквально одну секунду», но задаётся всегда.
4. Оверинжиниринг / закапывание: лишние сервисы, отдельные БД под витрины, фичи из головы (выбор газа через app). Правило интервьюера: сначала тривиальная схема «на одной машине», усложнение — только под конкретное число/отказ.
5. Потеря требований по ходу: не зафиксировал на доске — через 40 минут «кажется, я что-то упускаю». Фиксировать скоуп письменно и возвращаться к нему.
6. Мимо hot keys: партиционирование «по юзеру» без вопроса про знаменитостей/200 млн подписчиков — классика Instagram (§4.6).

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

• Смотреть/слушать: перед секцией — Вып.2 (Instagram) целиком как «репетиция темы»; при нехватке времени — только дебриф (последние 5 мин) + §4 выше.
• Наш каркас (methodology.md) совпадает с продемонстрированным в моках: требования → числа → одна машина → масштабирование. Моки добавляют то, чего нет в гайдах: темп и звук живой секции — пауз допустимо не больше, чем в Вып.2 до «выхода из ступора».
• Скрипт первых 10 минут (выучить): (1) функциональный скоуп + фиксация на доске; (2) R/W-соотношение, DAU→RPS, объём/день → ×N лет; (3) latency/CAP-приоритет одним предложением; (4) только потом первая стрелка.
• Числа для самопроверки на слух: 1,5 PB/день (Instagram), 5 ГБ → весь shortener в RAM, 100 МБ/с запись диска, 10K connections — из KB §1.2.
• Связанные материалы: lsd-polomodov-guide.md (взгляд интервьюера Tinkoff на тот же каркас), yandex-564132.md (формат Яндекса), KB §13 (маршрут запроса).