System design интервью: как проходит и как готовиться без опыта проектирования
System design интервью — это этап собеседования уровня middle+ и senior, на котором кандидат за 40–60 минут проектирует архитектуру системы вслух: например, сокращатель ссылок, ленту новостей или мессенджер. Правильного ответа не существует — оценивают процесс: умение собрать требования, оценить нагрузку, выбрать компоненты и осознанно проговорить компромиссы. Завалить этот этап идеальным, но молчаливым решением проще, чем неидеальным, но хорошо аргументированным.
Что на самом деле оценивают
Интервьюер смотрит не на количество упомянутых технологий, а на четыре навыка:
- Работа с неопределённостью. Задача формулируется намеренно расплывчато («спроектируйте Twitter»). Кандидат, который сразу рисует кубики, не спросив про масштаб — красный флаг.
- Количественное мышление. Прикидки на салфетке: сколько запросов в секунду, сколько данных в день, влезет ли в одну машину.
- Знание строительных блоков. Балансировщики, кеши, очереди, репликация, шардирование — и главное, когда что уместно.
- Осознанные компромиссы. Consistency vs availability, латентность vs стоимость, простота vs масштабируемость. Фраза «здесь я жертвую X ради Y, потому что…» — это то, за что ставят плюсы.
Фреймворк ответа: 4 шага
Держите структуру — она спасает, даже когда задача незнакомая:
1. Требования и масштаб (5–10 минут)
Задайте вопросы до того, как рисовать: кто пользователи и сколько их? Какие сценарии главные (читаем больше, чем пишем?)? Что важнее — доступность или строгая консистентность? Затем прикиньте цифры: DAU, RPS на чтение и запись, объём хранения в год. Ошибиться в 3 раза — нормально, важен порядок величин.
2. Базовая схема (10 минут)
Нарисуйте минимальную работающую систему: клиент → балансировщик → stateless-сервисы → база данных + кеш. Проговорите API: 3–5 ключевых эндпоинтов с методами. Не углубляйтесь раньше времени — скажите «это заготовка, дальше будем усиливать узкие места».
3. Углубление (15–20 минут)
Интервьюер направит: «а если пользователей станет в 100 раз больше?», «а как переживём падение дата-центра?». Здесь пригодятся паттерны:
| Проблема | Типовое решение |
|---|---|
| Не выдерживает чтение | Кеш (Redis), реплики на чтение, CDN для статики |
| Не выдерживает запись | Шардирование, очередь (Kafka) между приёмом и обработкой |
| Горячие ключи / знаменитости | Локальный кеш, разбиение горячего шарда, fan-out на записи vs чтении |
| Медленные тяжёлые операции | Асинхронная обработка через очередь + воркеры |
| Падения компонентов | Репликация, health checks, ретраи с backoff, идемпотентность |
4. Итог и слабые места (5 минут)
Сами назовите, что бы вы улучшили при большем времени и где система сломается первой. Это выглядит как зрелость, а не как слабость.
Типичные задачи и их «ядро»
- Сокращатель ссылок — генерация коротких ключей, редиректы с минимальной латентностью, счётчики кликов. Ядро: хеширование vs счётчик, кеш на чтение.
- Лента новостей — fan-out on write vs fan-out on read, кеш ленты, знаменитости.
- Чат/мессенджер — WebSocket-соединения, доставка и порядок сообщений, статусы онлайн.
- Rate limiter — алгоритмы token bucket / sliding window, распределённый счётчик.
- Загрузка файлов/видео — чанки, presigned URL, CDN, асинхронный транскодинг.
Разберите каждую по фреймворку выше — этого набора хватает на 80% интервью.
Как готовиться, если не проектировал большие системы
Отсутствие продового опыта с highload — не приговор: интервьюеры это понимают и оценивают рассуждение, а не послужной список.
- Изучите строительные блоки (1–2 недели): по одной вечерней сессии на тему — кеширование, очереди, репликация и шардирование, CAP-теорема, CDN. На каждую тему отвечайте себе: какую проблему решает, какой ценой.
- Разберите 5–7 классических задач из списка выше: сначала сами на бумаге по фреймворку, потом сверьтесь с разборами (книга «System Design Interview» Алекса Сюя — стандарт де-факто).
- Тренируйте счёт. 1 млн DAU × 10 действий = ~115 RPS в среднем, пик ×5–10. Такие прикидки должны отскакивать от зубов.
- Проговаривайте вслух с таймером. Как и с live coding, разрыв между «понимаю» и «формулирую голосом» — главное, что видит интервьюер. Полезно прогнать хотя бы одно мок-интервью в боевых условиях; если репетируете в одиночку, Interview Assistant подскажет структуру ответа на услышанный вопрос — удобно, чтобы не терять каркас рассуждения под стрессом.
Частые вопросы
На каком уровне спрашивают system design?
С middle+ почти всегда, у senior это ключевой этап. Junior-кандидатам иногда дают упрощённую версию («спроектируйте API для TODO-приложения») — проверяют базовое мышление, а не highload.
Нужно ли называть конкретные технологии?
Полезно, но вторично. «Очередь сообщений, например Kafka» звучит лучше, чем просто «Kafka» без объяснения роли. Если не работали с технологией — так и скажите: «не работал с Cassandra, но здесь нужна БД, оптимизированная под запись, по описанию она подходит».
Что делать, если задача совсем незнакомая?
Фреймворк тот же: требования → масштаб → базовая схема → углубление. Незнакомая предметная область компенсируется вопросами на первом шаге — их качество тоже оценивается.
Сколько времени нужно на подготовку?
При регулярных 4–6 часах в неделю — месяц на уверенный middle-уровень: неделя-две на строительные блоки, дальше разбор классических задач и проговаривание вслух.