---
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 |
|---|---|---|---|---|
| 1 | Вып.1 (`PZoueQ9kjCU`) | URL shortener | 58 мин | Эталонная последовательность от требований до схемы; задача-«разминка», на которой виден весь каркас |
| 2 | Вып.2 (`DzWY_zceCxk`) | Instagram (лента/фото) | 47 мин | **Тема нашего этапа 2** (лента соцсети); весь набор проблем: hot keys, знаменитости, push vs pull ленты |
| 3 | Стрим (`Ow88hoEnsq8`) | АЗС-сеть 25K точек, мультивалютность | 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 (маршрут запроса).