Interview playbook¶

Как пройти system-design собеседование. Тайминг, последовательность шагов, типовые вопросы, чек-листы и список книг. Это финальная сборка из всего, что ты прочитал.

Тайминг (45 минут)¶

gantt
    title System design interview
    dateFormat mm
    axisFormat %M min

    section Steps
    Уточнение требований    :0, 7
    Capacity estimation     :7, 12
    High-level дизайн       :12, 22
    Глубокое погружение     :22, 35
    Bottlenecks/wrap up     :35, 43
    Вопросы интервьюеру     :43, 45

Ключевые проверки времени.

5 минут — должен быть закончен etap «requirements».
12 минут — закончен capacity estimation.
22 минуты — high-level схема нарисована.
35–40 минут — обсуждены bottlenecks и trade-offs.
45 минут — есть вопросы интервьюеру (показывает интерес к компании).

5 шагов хорошего ответа¶

Шаг 1. Functional + non-functional requirements (5–7 мин)¶

Не торопись рисовать. Задавай вопросы. Это самая ценная часть.

Functional:
- Какие действия пользователя (post / read / search / ...)?
- Какие в скоупе, какие нет (например, реклама — нет)?
- Гарантии (доставка, порядок, дубликаты)?

Non-functional:
- DAU, MAU, RPS (peak vs avg)?
- Read/write ratio?
- Latency (p99 каких операций)?
- Consistency (strong / eventual)?
- Availability (99.9 / 99.99)?
- Storage growth?
- Geography?

📌 Лайфхак. Если интервьюер не отвечает конкретно — озвучь свои предположения вслух и зафиксируй: «допустим, 100M DAU, 10:1 read/write, p99 < 200 ms — двигаемся дальше».

Шаг 2. Capacity estimation (5 мин)¶

Грубые оценки на коленке. Важна логика, не точность.

DAU = 100M
posts/user/day = 5
posts/sec = 100M × 5 / 86400 ≈ 5800

read/write ratio = 50:1 → reads/sec ≈ 290k

storage:
  posts × bytes = 5800 × 86400 × 500B/post ≈ 250 GB/day
  год → 90 TB
  с учётом replication ×3 → 270 TB

Рассказывай вслух. Интервьюеру важно видеть, как считаешь.

Шаг 3. API design (3–5 мин)¶

POST /api/v1/posts
  Body: { text, attachments? }
  Headers: Idempotency-Key
  Response: 201 { id, created_at }

GET /api/v1/feed?cursor=...&limit=20
  Response: { items: [...], next_cursor }

📌 Чек-лист. REST или gRPC + причина. Idempotency на write. Cursor pagination, не offset. Auth.

Шаг 4. High-level architecture (10 мин)¶

Рисуешь основные компоненты и их взаимодействия. Не вдаёшься в детали — это будет в шаге 5.

graph LR
    User --> CDN
    CDN --> LB
    LB --> API
    API --> Cache[(Redis)]
    API --> DB[(Postgres)]
    API --> MQ[Kafka]
    MQ --> Workers
    DB --> Replicas

Объясни выбор каждого: «Postgres потому что ACID + структурированные данные; Redis для hot keys feed; Kafka для async fan-out».

Шаг 5. Deep dive + bottlenecks (10–15 мин)¶

Здесь интервьюер «копнёт» 1–2 темы. Будь готов:

Sharding strategy. По какому ключу, какие сложности.
Cache invalidation. Как обновляешь, что с stale, thundering herd.
Fault tolerance. Что если упал DB master? Replica lag? Network partition?
Hot keys / hot users. Justin Bieber problem.
Race conditions. Двойное списание, concurrent updates.
Monitoring / SLO. Какие метрики, как алёртишь.

Шаг 6. Wrap-up¶

Сам перечисли, что ещё можно улучшить, что не успел затронуть. Покажет зрелость.

"Что я не успел: rate limiting, anti-fraud, GDPR delete, multi-region.
Если хотите — могу углубиться."

Что говорить, что НЕ говорить¶

✅ Хорошие фразы¶

«Прежде чем рисовать, уточню...»
«Делаю предположение: ... Поправь, если не так.»
«Здесь trade-off между X и Y. Я выбираю X, потому что...»
«На моём опыте, в [компания/проект] эта же задача решалась через...»
«Узкое место здесь — Y. Если упрёмся, можно...»
«Я не уверен на 100%, но логика подсказывает...»

❌ Плохие фразы¶

«Возьмём NoSQL, так круче.» (без обоснования)
«Просто шардируем». (что за ключ? какая стратегия?)
«Используем Kafka.» (только Kafka? зачем здесь стрим?)
«Я никогда не работал с этим, но думаю...» (избегай — лучше скажи: «прямого опыта нет, но из понимания CAP я бы сделал...»)
Молчать в течение 30 секунд. Думай вслух.

Типовые вопросы по уровням¶

Junior (L1)¶

Что такое REST? Чем отличается от gRPC?
Что такое индекс в БД?
Чем отличается Redis от Postgres?
Что такое HTTP load balancer?
Что такое cache hit / miss?

📌 На L1 главное — знать термины и уметь объяснить простыми словами.

Middle (L2)¶

Спроектируй URL shortener.
Спроектируй простой чат на 1M пользователей.
Чем отличаются strong и eventual consistency?
Как ты бы шардировал Postgres на 5 ТБ?
Что такое circuit breaker и зачем?
Что такое idempotency-key?

📌 На L2 от тебя ждут обоснованных решений и понимания trade-offs.

Senior (L3)¶

Спроектируй Twitter feed на 300M MAU. Detail fan-out.
Как сделать exactly-once семантику в распределённой системе?
Спроектируй distributed rate limiter (10k RPS на пользователя).
Расскажи про инцидент в проде: что упало, как фиксили, что изменили после.
Сравни Kafka EOS и outbox pattern. Когда что выбрать?
Как ты бы построил multi-region failover для критичного API?

📌 На L3 ждут production experience и навыков архитектурного думанья.

Чек-лист «не забыть»¶

Распечатай и держи перед глазами в первые собесы.

Reading list¶

Книги (по приоритету)¶

📖 Designing Data-Intensive Applications, Martin Kleppmann. #1 must-read. Сделает из тебя нормального инженера.
📖 System Design Interview vol 1+2, Alex Xu. Рабочий учебник под собес. Точные решения для типовых задач.
📖 Building Microservices, Sam Newman. Если идёшь в микросервисную компанию.
📖 Site Reliability Engineering, Google (бесплатно онлайн). SLO/SLA, incident management, error budget.

Papers (для senior)¶

Dynamo: Amazon's Highly Available Key-value Store (2007). Базис для Cassandra/Riak/...
Bigtable: A Distributed Storage System for Structured Data (2006).
Spanner: Google's Globally-Distributed Database (2012). TrueTime.
The Raft Consensus Algorithm (2014). Заметно проще Paxos.
Kafka: a Distributed Messaging System for Log Processing (2011).
MapReduce: Simplified Data Processing on Large Clusters (2004).

Online ресурсы¶

System Design Primer (donnemartin) — каталог topic'ов на GitHub.
microservices.io — каталог паттернов.
highscalability.com — реальные системы из real companies.
Hussein Nasser на YouTube — БД и сети без воды.
ByteByteGo канал — короткие видео по System Design.
AWS Re:Invent — talks про реальные архитектуры.

Mock interviews¶

📌 Reps больше всего значат. Решай задачи на доске вслух, под таймер. Записывай и пересматривай — увидишь, где замолкаешь, где хаос.

С другом-инженером. Бесплатно, дружелюбно.
interviewing.io / Pramp. Анонимные mock'и с инженерами big-tech.
AI-ментор BoostMentor. Прокачка терминов и обратная связь, бесплатно в Telegram.

Финальный совет¶

Системный дизайн — навык, не знание. Зубрёжкой 10 кейсов не сдашь — спросят 11-й. Учись думать по шагам (требования → API → данные → масштаб → failure → монитор), и любая задача складывается. Если ты до этого пункта дошёл — у тебя уже есть фундамент. Дальше — повторение и реальные проекты.

📝 Подумай¶

Тебе сказали «спроектируй TikTok». Какие 5 первых уточняющих вопросов зададишь?
Интервьюер спрашивает: «А почему не Mongo вместо Postgres?». Как правильно ответить?
Ты застрял на 25-й минуте: схема нарисована, но не знаешь куда копать. Что делаешь?

Ответ

(a) read- или write-heavy? (b) сколько MAU/DAU? (c) длина видео и объём storage? (d) какая latency на старт воспроизведения? (e) feed — chronological или ranked (recommendation)? + бонус: «приватные аккаунты в скоупе?», «messaging?».
«У нас структурированные данные с транзакциями (заказы, платежи) — Postgres даёт ACID. Mongo — гибкая схема без транзакций между коллекциями. Здесь предсказуемая схема и нужны JOIN'ы (пользователи + заказы). Если бы данные были более дикие (event log с разной структурой) — Mongo бы рассмотрел.»
Сам предложи углубление: «Хочешь углубимся в шардирование? Или failure modes? Или cache invalidation?» — пусть интервьюер выберет. Это лучше, чем молчать.

Удачи на собесе. И помни: лучшие инженеры тоже не знают всего — они просто думают вслух и не боятся trade-offs. Возвращайся к index.md или конкретным темам, когда нужно освежить.