System design интервью: как готовиться без паники

Я провожу system design собеседования с 2019 года. Сначала как старший разработчик, потом как тимлид и руководитель платформы. За эти годы у меня накопилась тысяча с лишним проведённых интервью и сотни кандидатов, которых я готовил к этому формату. Главный вывод: 90% провалов — не из-за слабых технических знаний, а из-за плохо структурированного диалога.

В этой статье — как я готовлюсь к интервью сам и как готовлю мидлов и сеньоров. Без волшебных шаблонов, но с конкретным планом.

Что вообще проверяют

System design интервью существует в двух вариантах. На уровне сильного мидла или младшего сеньора (пожалуй, всё, кроме staff) проверяют умение мыслить в нескольких слоях:

• Уточнять требования, прежде чем рисовать схемы. Кандидаты, которые сразу идут чертить — теряют до 30 минут на нерелевантной задаче.
• Декомпозировать систему: поверх каких компонентов выложен сервис, как они общаются.
• Знать про узкие места, понимать пределы технологий. Условный «один Postgres до 100k QPS на запись» — это уже признак мидла.
• Защищать решения. «Почему PostgreSQL, а не MongoDB» — должен быть ответ.
• Не уходить в перфекционизм. На 60 минут невозможно нарисовать всю систему.

На уровне сеньора и staff добавляют: масштабирование на десятки регионов, согласованность данных, миграции, инциденты, организационные ограничения (за чьим бэклогом сидит этот компонент).

Базовый шаблон ответа на 60 минут

Время разбито на четыре блока. Минута в минуту никогда не получается, но шаблон даёт ориентир.

1. 5–8 минут — уточнение требований. Functional (что система должна делать) и non-functional (RPS, SLA, размер записи).
2. 10 минут — высокоуровневая архитектура. Грубая схема компонентов и их связей.
3. 30 минут — детальное обсуждение. Хранилища, индексы, очереди, кэши, протоколы.
4. 10–15 минут — узкие места и расширение. Что произойдёт при росте нагрузки в 10 раз, как увеличить пропускную способность.

Запомни: интервьюер ждёт диалога. Если ты говоришь без перерыва 10 минут, он не успевает копать в интересные ему места. Делай паузы.

Уточнение требований — самый важный блок

Я слышу, как кандидаты на «спроектируй YouTube» сразу начинают рисовать CDN. На мой вопрос «а что вообще нужно от системы» отвечают «ну, видео». А мне нужно знать:

• Сколько пользователей, какой DAU.
• Какой средний размер видео, какая длительность.
• Откуда смотрят: один регион, весь мир.
• Лимит на загрузку: сколько может загружать один пользователь.
• Что важнее: latency, пропускная способность, стоимость.
• Какие есть ограничения: бюджет, команда, существующая инфраструктура.

Этот список — короткий. Но он определяет 90% дальнейших решений. Если DAU — 100 человек, нам не нужен CDN с 30 PoP, можно одной коробкой обойтись.

Полезный приём: «прежде чем перейти к архитектуре, я хочу зафиксировать вводные». И список из шести пунктов на доске. Дальше любая разработка опирается на эти цифры.

Распространённые задачи, к которым стоит готовиться

За пять лет звучат примерно одни и те же кейсы. Вот мой список фавориты, который покрывает 80% реальных интервью:

1. Сервис укорачивателя ссылок (TinyURL).
2. Лента новостей (Twitter-like, главная страница соцсети).
3. Чат на миллион пользователей.
4. Поиск с автодополнением.
5. Хранилище и просмотр видео (мини-YouTube).
6. Сервис уведомлений.
7. Геораспределённая поездная очередь (Uber-like dispatch).
8. Платёжный сервис.
9. Лимитёр API (rate limiter как сервис).
10. Файловое хранилище (Dropbox-like синхронизация).

Бери этот список, разбирай по одной задаче в неделю. Через два месяца ты увидишь, что 11-я звучит как 7-я с другим интерфейсом.

Шаблонные блоки, которые нужно знать

В большинстве задач используются одни и те же кирпичи. Просто читать про них недостаточно — нужно понимать, когда брать.

Базы данных

PostgreSQL — дефолт для большинства задач. Реляционность, транзакции, индексы, неплохо тянет до 30k–80k QPS на одной коробке (с тюнингом). Шардирование — за пределами 100k.

MongoDB / DynamoDB — когда нужен горизонтальный масштаб без сложной модели данных. Нет джойнов, нужно денормализовать.

ClickHouse / другие колоночные — для аналитики и time-series. Не используй как OLTP.

Redis — кэш и быстрая структура данных. Ограничен памятью одной ноды (или кластера) — 100 ГБ-ный кэш в Redis нормален, 10 ТБ — повод задуматься.

Очереди

Kafka — большие пропускные способности, persistent log, exactly-once при правильной настройке. Не для коротких задач (миллион в день).

RabbitMQ — гибкая маршрутизация, классический брокер.

SQS / Yandex Message Queue — managed-альтернативы.

Redis Streams — легче Kafka, годится до сотен тысяч сообщений в секунду.

Кэширование

Знай минимум три стратегии: cache-aside (приложение само пишет в кэш и БД), write-through (запись через кэш в БД), write-behind (асинхронная запись в БД из кэша). Каждая даёт разные гарантии и сложности.

Балансировка

L4 (TCP) и L7 (HTTP) балансировка. Round-robin, least connections, hash. Знай, что DNS как балансировщик плохо ловит падения нод (низкое TTL спасает, но не везде доступен).

Согласованность данных

CAP теорема в формате «выбираешь консистентность или доступность при network partition». Eventual consistency ок там, где можно (лента социальной сети, статистика). Не ок там, где нельзя (банковские переводы).

2PC, Saga, Outbox — для распределённых транзакций. Лучший ответ почти всегда — «избегаем распределённых транзакций, проектируем без них».

Конкретный пример: укорачиватель ссылок

Покажу, как через шаблон решается задача за 60 минут.

1. Требования

• Создание короткой ссылки из длинной.
• Редирект по короткой на длинную.
• Опционально: статистика кликов, кастомный slug, истечение срока.
• Read-heavy: 100:1 в пользу redirect.
• 1 млрд новых ссылок в год → 30 ссылок в секунду на запись.
• 10 млрд кликов в год → 300 редиректов в секунду в среднем, пик 3000.
• SLA: redirect < 100 ms p99.

2. Высокий уровень

Клиент → API Gateway → сервис укорачивателя → Redis cache → PostgreSQL → ответ. Аналитика отдельным потоком в Kafka.

3. Детально

Генерация slug: Base62 от автоинкремента. На 10^11 ссылок хватит 7 символов (62^7 ≈ 3.5×10^12). Не используем хеш длинной ссылки — коллизии и плохая лексикография.

Запись: INSERT в Postgres → CDC через Debezium → Kafka → ClickHouse для аналитики и поиска по аудиту.

Чтение: сначала Redis (TTL 24 часа), при промахе — Postgres, потом обновляем кэш. Cache hit ratio в этой задаче обычно 95%+ из-за power law (топ-1% ссылок собирает 90% трафика).

Аналитика кликов: пишем в Kafka, агрегируем в ClickHouse. Не блокируем редирект — fire-and-forget.

4. Узкие места

• Постгрес упрётся примерно в 30k QPS на чтение, но мы туда не ходим — кэш покрывает. Запись — 30 RPS, никак не упрёмся.
• Redis: 100M ключей × 200 байт = 20 ГБ. Поместится в одну ноду или маленький кластер.
• Сервис укорачивателя — горизонтально масштабируется, ноды без состояния.
• Kafka — для аналитики держит миллионы EPS.

5. Что улучшать

• Геораспределённое чтение — реплики Postgres + Redis в каждом регионе.
• Защита от malicious URLs: проверка против Safe Browsing.
• Кастомные slug — отдельная таблица, проверка коллизий через unique constraint.
• Истечение — добавить expires_at, фоновый GC через partitioned table.

Чего избегать

• Хайп-стек просто потому, что вы про него читали. NewSQL, blockchain, GraphQL — нужны там, где нужны.
• Лишние компоненты. Каждая стрелочка на схеме — это операционная стоимость и точка отказа.
• Уход в детали без необходимости. Тип данных колонки в Postgres — это не system design, это код.
• Молчание. Думай вслух. Тишина в 30 секунд — потерянная возможность показать ход мыслей.
• Магические цифры без обоснования. «Поставим 100 нод» — это не дизайн. «300 RPS на ноду, нужно 1000 RPS, итого 4 ноды + 1 запас» — это дизайн.

План подготовки на 4 недели

Если до собеседования месяц, делай так:

1. Неделя 1: книги «Designing Data-Intensive Applications» (Kleppmann) разделы про репликацию, шардинг, согласованность. Альт. — конспекты в роадмапе systemdesign.one. Параллельно — задачи 1, 2 из списка выше.
2. Неделя 2: задачи 3, 4, 5. Каждую разбираешь и записываешь решение текстом — это ловит провалы в логике.
3. Неделя 3: задачи 6, 7, 8. Пробуй решать с таймером 60 минут.
4. Неделя 4: 9, 10. Минимум 2 mock interview с другом или ментором. Сам себе плохой интервьюер.

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

Что запомнить

System design — это диалог про trade-offs. Идеального решения нет, есть подходящее под требования. Уточняй вводные, веди разговор, защищай решения. Если интервьюер задаёт встречный вопрос — это хорошо, тебе подкидывают идеи, а не ловят на ошибке.