Секция system design (SD) проверяет не знание конкретной «правильной» архитектуры, а то, как вы рассуждаете: задаёте ли вопросы, считаете ли нагрузку, видите ли компромиссы. В российских компаниях её проводят на уровнях middle+ и senior: в Яндексе, Авито, Т-Банке, Ozon, VK это отдельный этап на 45-90 минут. Для junior её обычно нет, у middle бывает облегчённой.
Что оценивает интервьюер
- Структура. Вы сами ведёте разговор по шагам, а не прыгаете сразу в «возьмём Kafka».
- Требования. Уточняете, что именно строим и для какой нагрузки.
- Числа. Делаете грубую оценку и используете её для решений.
- Компромиссы. Говорите «выбираю X, потому что..., цена этого...».
- Глубина. На одном-двух узких местах уходите в детали.
План на 45-60 минут
- Требования (5-7 мин). Функциональные: что делает пользователь (3-5 главных сценариев). Нефункциональные: число пользователей, DAU, задержка, доступность, консистентность, география. Явно скажите, что не делаете.
- Оценка нагрузки (3-5 мин). RPS на чтение и запись, объём данных за год, трафик.
- API (3-5 мин). 3-5 ключевых эндпоинтов: метод, путь, параметры, ответ, пагинация.
- Модель данных (5 мин). Сущности, ключи, выбор хранилища под паттерн доступа.
- Высокоуровневая схема (10 мин). Клиент, балансировщик, сервисы, БД, кеш, очередь. Пройдите по ней путь запроса.
- Узкие места и масштабирование (10-15 мин). Где упадёт при росте в 10 раз, горячие ключи, отказ узла, мониторинг.
Оценка нагрузки: опорные числа
Считайте грубо, порядками. В сутках около 86 400 секунд, удобно округлять до 10^5.
- 1 млн запросов в сутки ≈ 12 RPS в среднем.
- 100 млн в сутки ≈ 1 200 RPS в среднем, пик обычно в 2-3 раза выше.
- Чтение к записи часто 10:1 или 100:1 (ленты, каталоги).
Ориентиры задержек (порядки, не точные значения):
| Операция | Порядок |
|---|---|
| Обращение к L1-кешу | ~1 нс |
| Чтение из RAM | ~100 нс |
| Случайное чтение с SSD | ~100 мкс |
| Круг внутри дата-центра | ~0,5 мс |
| Запрос в Redis по сети | ~0,5-1 мс |
| Простой запрос в PostgreSQL по индексу | ~1-5 мс |
| Москва - Новосибирск и обратно | ~50 мс |
| Москва - США и обратно | ~120-150 мс |
Пример: сервис коротких ссылок, 100 млн новых ссылок в месяц. Запись: 10^8 / (30 × 10^5) ≈ 40 RPS. Чтение при 100:1 ≈ 4 000 RPS, в пике ~10 000. Одна запись ~500 байт, за 5 лет 6 млрд записей ≈ 3 ТБ. Вывод: чтение важнее записи, нужен кеш, данные помещаются в шардированную БД средних размеров.
Частые ошибки
- Начать рисовать без вопросов о требованиях.
- Назвать модные технологии без причины: «тут Kafka, тут Cassandra».
- Считать до единиц вместо порядков и потратить на это 15 минут.
- Молчать. Интервьюер оценивает ход мысли, его нужно проговаривать.
- Не реагировать на подсказки: если интервьюер спрашивает «а что если узел упадёт?», это приглашение углубиться.
- Делать вид, что решение без минусов. У любого выбора есть цена.
Как говорить о компромиссах
Хорошая формула: «Варианты A и B. A проще и даёт строгую консистентность, но хуже масштабируется на запись. Под нашу нагрузку 40 RPS записи хватит A, поэтому беру его, а при росте перейду на B».
Что спросят на собесе
- Спроектируйте сервис X: интервьюер ждёт, что вы начнёте с вопросов.
- Посчитайте RPS и объём хранения за 5 лет.
- Какие нефункциональные требования важны для этой системы и почему.
- Где узкое место вашей схемы и что будет при росте нагрузки в 10 раз.
- Почему вы выбрали именно эту БД.