System design секция пугает кандидатов сильнее алгоритмов, потому что у неё нет «правильного ответа». Здесь не проверяют, помните ли вы конкретный алгоритм — проверяют, как вы думаете: умеете ли разбить расплывчатую задачу на части, назвать trade-off’ы и довести систему от требований до работающей архитектуры за 45 минут. Хорошая новость: это навык, который тренируется по понятному каркасу.

Что проверяет system design и кому его дают

Секция проверяет инженерную зрелость: способность работать с неопределённостью, структурно мыслить и аргументировать решения. Интервьюер смотрит не на «знаете ли вы Kafka», а на то, понимаете ли вы, зачем и когда её ставить.

Классически system design дают на senior и staff позиции. Но в 2026 году картина сдвинулась: в РФ-компаниях секцию всё чаще получают и middle-кандидаты — в упрощённом формате, где нужно спроектировать один сервис без экстремального масштаба. Поэтому, если вы метите выше джуна, готовиться стоит заранее, а не «когда позовут на senior».

Разница в ожиданиях по грейдам ощутимая. От middle ждут, что человек спроектирует работающую систему: разумный API, адекватное хранилище, базовое кэширование. От senior — что он сам поднимет тему масштаба, отказоустойчивости и назовёт цену каждого решения. От staff — что он будет думать про эволюцию системы во времени, про границы команд и про то, как архитектура переживёт рост ×100. Понимание, на какой грейд вы идёте, помогает калибровать глубину ответа: middle, закопавшийся в тонкости consensus-алгоритмов, тратит время не туда, а senior, оставшийся на уровне трёх коробочек, выглядит слабо.

Каркас ответа за 45 минут

Главное оружие на секции — не эрудиция, а структура. Один и тот же каркас применяется к любой задаче, и интервьюеры считывают его положительно: видно, что человек ведёт диалог системно.

1. Уточнение требований (5–7 минут). Самый недооценённый шаг — и причина около 40% провалов. Кандидат слышит «спроектируй Twitter» и сразу рисует базу. Вместо этого выясните:

  • Functional: что система должна делать? Какие основные сценарии? Что в скоупе, а что нет?
  • Non-functional: сколько пользователей, какая нагрузка, требования к latency, консистентности, доступности? Read-heavy или write-heavy?

Не угадывайте — задавайте вопросы вслух. Это не слабость, а то, что делают senior-инженеры.

2. Оценки на салфетке (3–5 минут). Back-of-envelope расчёты: прикиньте RPS, объём хранимых данных, пропускную способность. Если 100 млн DAU пишут по 2 поста в день — это ~2300 записей/сек в среднем и в разы больше в пике. Эти цифры дальше диктуют выбор хранилища и стратегию масштабирования. Не нужна точность — нужен порядок величины.

3. API-дизайн (3–5 минут). Опишите ключевые эндпоинты: сигнатуры, параметры, что возвращают. POST /tweets, GET /feed?userId=&cursor=. Это закрепляет контракт между компонентами и показывает, что вы думаете о клиентах.

4. Схема данных и выбор хранилища (5–7 минут). Какие сущности, связи, индексы. И главное — почему это хранилище: реляционная БД ради транзакций и сложных запросов, key-value ради скорости и масштаба, документная под гибкую схему, поисковый движок под full-text. Всегда обосновывайте выбор нагрузкой из шага 2.

5. Масштабирование (10–12 минут). Здесь разворачивается основная глубина:

  • Кэширование — что и где кэшируем (Redis, CDN для статики), стратегия инвалидации.
  • Шардирование — по какому ключу бьём данные, как избегаем горячих шардов.
  • Очереди — где нужна асинхронность (Kafka/RabbitMQ): рассылка уведомлений, fan-out ленты, тяжёлая постобработка.
  • Репликация — read-реплики под read-heavy нагрузку, master-slave vs multi-master.

6. Надёжность (5 минут). Чем закрываете отказы: failover и отсутствие single point of failure, идемпотентность операций (чтобы повтор запроса не задвоил платёж), мониторинг и алертинг. Упоминание этого шага отличает senior от middle.

Каркас не нужно проходить буквально по таймеру — это ориентир, а не сценарий. Часто интервьюер сам прерывает на середине и уводит в один компонент: «окей, а как именно вы шардируете эту таблицу?». Это нормально и даже хорошо — значит, верхнеуровневая часть его устроила и он копает глубину. Держите в голове, что вы не обязаны покрыть всё: лучше глубоко проработать два ключевых компонента, чем поверхностно перечислить десять.

Типовые задачи и что в них главное

  • Лента соцсети. Ключевая дилемма — fan-out on write vs fan-out on read. Предрассчитывать ленты подписчиков заранее или собирать на лету? Отдельно обсудите проблему «звёзд» с миллионами подписчиков.
  • Шортнер ссылок. Главное — генерация коротких уникальных ключей (base62, счётчик vs хеш) и адское соотношение read/write в пользу чтения, то есть агрессивное кэширование.
  • Чат / мессенджер. WebSocket vs long polling, доставка и порядок сообщений, статусы «доставлено/прочитано», хранение истории, presence-сервис онлайн-статусов.
  • Система уведомлений. Fan-out через очередь, несколько каналов (push/email/SMS), идемпотентность и дедупликация, ретраи и троттлинг, чтобы не залить пользователя.
  • Rate limiter. Алгоритмы (token bucket, sliding window), где хранить счётчики (Redis), распределённый rate limiting через несколько узлов и консистентность лимитов.

В каждой задаче интервьюера интересует не «нарисовать всё», а назвать центральный trade-off и аргументированно выбрать сторону.

Частые ошибки

  • Рисовать архитектуру до требований. Самый типичный провал. Сначала вопросы, потом коробочки.
  • Замолкать. Тишина читается как «не знаю». Думайте вслух — интервьюер оценивает ход мысли, а не только итог.
  • Спорить с интервьюером. Если вас толкают в сторону — это подсказка, а не нападение. Берите её.
  • Сыпать buzzword’ами без обоснования. Сказать «поставим Kafka и Kubernetes» без объяснения зачем — хуже, чем не сказать вовсе. Каждый компонент должен решать названную проблему.
  • Не называть trade-off’ы. Любое решение имеет цену. «Возьмём NoSQL» без «…ценой того, что потеряем транзакции и сложные join» — половина ответа.
  • Over-engineering. Тащить микросервисы, Kubernetes и event sourcing в задачу, где хватило бы монолита с одной БД. Сложность должна быть оправдана требованиями из шага 1, а не желанием показать кругозор. Умение сказать «на таком масштабе это лишнее» ценится не меньше, чем знание сложных паттернов.

Ресурсы для подготовки

База чтения короткая, но обязательная: «System Design Interview» Алекса Сюя (Alex Xu) — лучший разбор именно интервью-формата с готовыми решениями типовых задач, и «Designing Data-Intensive Applications» Мартина Клеппмана (DDIA) — фундамент, без которого вы не выйдете за пределы заученных схем.

Чтение даёт теорию, но секцию проваливают на диалоге, а не на знаниях. Поэтому ключевое — практика говорения:

  • Тренировка с LLM. Современные модели отлично играют интервьюера в system design: задают уточняющие вопросы, замечают дыры, толкают в глубину. Готовый промпт для 45-минутной system design сессии и разбор, что AI делает хорошо, а где не заменяет человека, — в гайде подготовка к собеседованию с LLM.
  • Мок-собеседование с живым инженером. LLM не воспроизводит давление, паузы и реакцию на ваше «поплыл». Отработать диалог под стрессом можно только с человеком — мок-собеседование с senior-инженером, который ведёт секцию как настоящий интервьюер и даёт развёрнутую обратную связь.

Связка «теория из книг + сессии с LLM + 2–3 живых мока» закрывает почти все слабые места. В IT-ХОЗЯЕВА мок-собеседования (включая направление system design) и база практикующих менторов входят в тариф ХОЗЯИН за 1000 ₽/мес — это дешевле одной разовой сессии на платных сервисах, а практиковаться можно сколько нужно.

System design — не про вызубренные ответы, а про натренированный каркас и спокойный диалог. Отработайте структуру до автоматизма, прогоните типовые задачи вслух, и секция перестанет быть лотереей.