System design на собеседовании: как подготовиться, что рисовать и как отвечать

Вы уверенно решаете задачи на алгоритмы, знаете, чем BFS отличается от DFS, и можете с закрытыми глазами написать бинарный поиск. Потом на собеседовании звучит: «Спроектируйте ленту новостей для миллиона пользователей». На доске появляется прямоугольник с надписью «сервер» и стрелочка в сторону базы данных. И вы останавливаетесь, потому что не знаете, что рисовать дальше.

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

На собеседовании по system design оценивают ход рассуждений. Можно нарисовать идеальную схему и провалиться, потому что молчали. А можно показать не самое оптимальное решение и получить оффер, потому что задавали правильные вопросы, объясняли выбор и не боялись признать слабые места решения. В статье — каркас ответа, чеклист тем и график подготовки. 

Читайте, как пройти собеседование в ИТ-компанию, в отдельном материале.

Что проверяют на собеседовании по system design

Интервьюер в первую очередь наблюдает за тем, как вы ведёте диалог. Задаёте ли уточняющие вопросы, прежде чем что-то рисовать. Объясняете ли, почему выбрали именно эту базу данных. Замечаете ли компромиссы и узкие места. Способность принимать решения при неполных вводных здесь весит больше, чем готовое решение из книжки.

Дальше разговор идёт о свойствах системы:

Обсуждать эти свойства придётся применительно к конкретной задаче, а не в общем виде.

Подготовку часто губит установка, будто нужно запомнить архитектуры Uber, YouTube и прочие. Но делать это не нужно. Гораздо полезнее разобраться в строительных блоках — базах данных, кэшах, очередях, балансировщиках, CDN — и научиться собирать из них что-то осмысленное под заданные требования. 

Как устроена секция: формат и тайминг

Формат примерно одинаков в большинстве компаний: около часа, из которых минут сорок на само проектирование, остальное — знакомство и ваши вопросы. Инструмент — онлайн-доска вроде Miro или Excalidraw. Если собеседование офлайн, могут дать бумагу и маркер, и это не всегда проще — на бумаге сложно перерисовать схему, когда понял, что забыл про очередь.

Тайминг ориентировочный и зависит от компании, но общая логика у всех примерно одинаковая. Около 15 минут уходит на уточнение требований и прикидки нагрузки. 5-10 минут на API и интеграции. Около 10 минут на модель данных. Ещё  15 — на схему архитектуры. В конце — расчёт ресурсов на горизонт 3-5 лет роста. Если задача сложная, этапы могут перемешиваться, но последовательность «требования → цифры → данные → архитектура → детали → проверка» остаётся.

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

Примерная разбивка на 45-минутную секцию разобрана в коммуникационном фреймворке для data engineering-интервью: 

Каркас ответа за восемь шагов

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

Проговаривайте каждый шаг вслух. Интервьюеру важно слышать, на каком этапе вы находитесь и почему переходите к следующему. Если вы замолчали на 10 минут и рисуете, он не понимает, что происходит в вашей голове. Со стороны это выглядит так, будто вы не умеете объяснять свои решения, а на реальной работе это половина профессии.

Шаг первый. Требования. Выясните, сколько пользователей, какой сценарий главный, что делаем с офлайном, какая допустимая задержка. Зафиксируйте ориентиры: доступность 99,9%, отклик до 200 мс, объём данных за год. Пропустить этот шаг — значит проектировать вслепую.

Шаг второй. Прикидки. За пару минут посчитайте RPS, объём хранилища и исходящий трафик из числа пользователей и частоты действий. Допустим, 100 млн пользователей, каждый открывает ленту десять раз в день. Это миллиард запросов в сутки, примерно 12 тысяч RPS. Если каждый ответ весит 50 килобайт, исходящий трафик — около 600 мегабайт в секунду. При среднем размере записи в базе 1 килобайт и сотне миллионов новых записей в день за год набегает примерно 36 терабайт. Эти числа потом пригодятся, когда будете выбирать базу и решать, нужен ли кэш.

Шаг третий. Модель данных. Какие сущности, какие связи, как хранить. Здесь уместно вспомнить материал о том, как выбрать базу данных для проекта. Реляционная база подойдёт для транзакций и сложных связей, документная — для гибкой схемы и быстрых чтений. Если задача про ленту новостей, скорее всего понадобится и то и другое.

Шаг четвёртый. Верхнеуровневая схема. Минимальный набор блоков: клиент, балансировщик, сервис приложения, хранилище, кэш, очередь. Не углубляйтесь в детали ни одного из них. Цель — общая картина, с которой согласны и вы, и интервьюер. Про выбор между монолитом и микросервисами стоит узнать во всех подробностях, но на этом шаге достаточно показать, где какая часть живёт.

Шаг пятый. API-контракты. Эндпоинты описываются до того, как рисуется внутренняя начинка. Клиент вызывает POST /messages — что передаёт, что получает, какой формат ответа. Пять минут на это хватает, если не уходить в детали авторизации.

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

Шаг седьмой. Проверка решения. Прогоните сценарий от запроса пользователя до ответа. Что произойдёт, если упадёт один из сервисов. Что будет, если нагрузка вырастет в десять раз. Какой компонент откажет первым.

Шаг восьмой. Разбор самого интересного узла. Интервьюер может попросить углубиться в конкретную часть. Это не значит, что предыдущие шаги были зря. Это значит, что он хочет проверить глубину.

Что нужно знать до собеседования

Тем много, но запоминать всё подряд не нужно. Достаточно понимать ключевые механизмы и уметь объяснить их за минуту. Если вы не работали с микросервисной архитектурой, узнайте, что такое микросервисы, до беседы. В таблице — ориентир по темам и проверочным вопросам.

Тема	Минимум, который спрашивают	Материал для повторения
Балансировка нагрузки и обратный прокси	Чем отличается L4 от L7, как распределяется трафик, что такое health check	Что такое nginx
Кэширование и инвалидация	Какие стратегии кэширования бывают, как не отдать устаревшие данные	Redis: что это такое и как им пользоваться Кэширование API на Python: lru_cache и Redis
Репликация и шардирование	Синхронная и асинхронная репликация, как выбрать ключ шардирования	Клеппман, глава 5
Реляционная база или документная	Когда выбирать каждую, какие компромиссы	Как выбрать базу данных для проекта
Очереди и асинхронная обработка	Зачем нужна очередь, что такое backpressure, как гарантировать доставку	Материалы по Kafka и RabbitMQ
Согласованность и CAP	Что такое CAP-теорема, какие системы выбирают CP, какие AP	Клеппман, глава 9
Идемпотентность и повторные запросы	Как не создать дубль при повторной отправке	Материалы по идемпотентным ключам
CDN и статика	Зачем выносить статику, как работает кэширование на краю	Материалы по CDN
Мониторинг и трассировка	Что логируем, как понять, что система деградирует	Материалы по observability

По каждой теме нужно уметь ответить на проверочный вопрос за минуту. Не написать статью, не нарисовать схему — просто объяснить суть. Если не получается, значит, тема не закрыта.

Чего ждут от джуна, мидла и сеньора

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

Если вы готовитесь к позиции джуна или мидла, начните с базы данных. Вопросы по PostgreSQL часто всплывают на секции, и их стоит проработать отдельно.

Этап	Джун	Мидл	Сеньор
Требования	15–20 минут	10–15 минут	5–10 минут
Верхнеуровневая схема	10–15 минут	10 минут	5–10 минут
Детализация	5–10 минут	10–15 минут	15–20 минут
Обсуждение компромиссов и развития	5 минут	5–10 минут	10–15 минут

У джуна больше времени уходит на требования и верхнеуровневую схему. У сеньора — на детализацию и обсуждение. Это не значит, что сеньору проще. Просто акценты другие. Вопросы для джунов чаще про сокращатель ссылок и rate limiter, для мидлов — про ленту новостей и систему уведомлений, для сеньоров — про сложные распределённые системы. Про критерии на разных уровнях хорошо написано в гайде по подготовке к собеседованию на Python-разработчика.

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

Первая неделя. Закрыть базу по темам из чеклиста. Разобрать по одному реальному примеру на каждую тему. Не нужно решать задачи — нужно понять, как устроены системы, которые вы используете каждый день. Как работает балансировщик в вашем проекте. Как кэшируются ответы API. Где стоят очереди. Проверка результата: можете объяснить любую тему из таблицы за минуту, без подглядывания. 

Для тех, кто только начинает путь и хочет выстроить обучение упорядоченно, на КОДе есть статья Бэкенд с нуля в 2026 —  там собраны базовые темы и последовательность шагов.

Вторая неделя. Отработать каркас на двух простых задачах с секундомером, без подглядывания в заметки. Сокращатель ссылок и система уведомлений — оптимальные стартовые задачи. Проговаривайте каждый шаг вслух, даже если находитесь в одиночестве. Записывайте себя на видео и смотрите. Проверка результата: укладываетесь в сорок минут на задачу и не теряете нить на середине.

Третья неделя. Разобрать задачи с высокой нагрузкой. Добавить расчёты и обсуждение отказов. Что произойдёт, если база данных упадёт. Что произойдёт, если сеть между дата-центрами пропадёт на минуту. Что произойдёт, если один из сервисов начнёт отвечать медленно. Проверка результата: можете назвать точку отказа и объяснить, как система восстановится.

Четвёртая неделя. Mock-интервью с коллегой и разбор записи. Попросите его задавать неудобные вопросы: «А что если нагрузка вырастет в сто раз?», «А почему не использовать другую базу?». Проверка результата: вы не сбиваетесь, не защищаетесь, а спокойно объясняете компромиссы.

Если до собеседования осталось несколько дней, уберите из плана всё, кроме первых двух шагов каркаса — требований и верхнеуровневой схемы. Их выкидывать нельзя. Остальное можно проговорить на ходу.

Как тренироваться

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

Рекомендации: 

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

Типовые задачи system design и что в них проверяют

Задач на system design много, но большинство сводится к нескольким паттернам. Если вы разберёте эти паттерны, незнакомая формулировка на собеседовании перестанет пугать: вы быстро узнаете, что именно проверяют, и построите ответ по знакомой логике.

Сокращатель ссылок проверяет, как вы генерируете короткие коды и что делаете при коллизии, когда два пользователя получают один и тот же код. 

Лента новостей — это fan-out: вы должны понимать, что для миллиона подписчиков стратегия «писать во все ленты при публикации» не масштабируется, и уметь объяснить гибридный подход. 

Мессенджер проверяет доставку и порядок сообщений: WebSocket или long polling, как гарантировать, что сообщения не перепутаются и не потеряются. 

Сервис загрузки видео — хранение и обработка больших файлов: чанкованная загрузка, транскодирование в очереди, CDN для раздачи. 

Поиск ближайших исполнителей — про геоиндексы: понимаете ли вы, как работает геохеш или R-tree, и почему нельзя перебрать всех. 

Счётчик просмотров — приблизительный подсчёт при высокой нагрузке: знаете ли вы про шардированные счётчики и почему точное число здесь не нужно.

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

Требования. Спрашиваем: сколько ссылок в день? Допустим, сто миллионов. Какое соотношение чтения и записи? Сто к одному. Ссылки должны жить пять лет? Да. Нужна ли аналитика кликов? Базовая — да. Нужны ли кастомные короткие ссылки? Не критично.

Прикидки. Сто миллионов новых ссылок в день — примерно 1200 записей в секунду. Сто к одному на чтение — 120 тысяч запросов в секунду. При размере записи 500 байт и хранении за пять лет — около 90 терабайт. Система должна быть оптимизирована под чтение.

Модель данных. Две сущности: ссылка (короткий код, длинный URL, дата создания, срок жизни) и клик (короткий код, время, IP, user agent). Ссылки можно хранить в реляционной базе, клики — в колоночной или в отдельном хранилище для аналитики.

Верхнеуровневая схема. Клиент → балансировщик → сервис сокращения → генератор ключей → база. Для чтения: клиент → балансировщик → сервис редиректа → кэш → база. Отдельно — сервис аналитики, который получает события кликов асинхронно.

API. POST /shorten принимает длинный URL, возвращает короткий код. GET /{code} возвращает редирект 301 или 302. GET /analytics/{code} возвращает статистику.

Детализация. Генерация ключей — base62 из автоинкрементного ID или хеш с проверкой коллизий. Кэш — Redis для горячих ссылок, TTL 24 часа. Инвалидация — по истечении срока жизни. База — шардирование по первому символу кода.

Проверка. Что если генератор ключей упадёт? Используем распределённый счётчик или диапазоны ID. Что если кэш переполнится? Вытеснение по LRU. Что если база недоступна? Очередь на запись, ретраи.

Углубление. Интервьюер может спросить про коллизии. Отвечаем: вероятность мала, но проверяем при записи, и при коллизии генерируем новый код. Или используем Snowflake ID с гарантией уникальности.

Ошибки, из-за которых секцию заваливают

Провалы на system design редко связаны с незнанием технологий. Чаще всего кандидат приходит с достаточной базой, но теряет баллы на организации ответа.

Пять ошибок, которые встречаются чаще всего, с последствием и способом исправить:

Каждая ошибка стоит кандидату баллов. Если получится проговорить эти пять сценариев на mock-интервью до реальной секции, шансы пройти заметно вырастут.

Частые вопросы

Спрашивают ли system design у джунов? 

Да, но по-разному. В некоторых компаниях джунам дают упрощённые задачи вроде сокращателя ссылок или rate limiter. «В других system design появляется только с мидл-уровня. Спрашивайте у рекрутера, что входит в секции.

Нужно ли знать конкретные технологии или достаточно принципов?

Принципы важнее. Но если вы называете технологию, будьте готовы объяснить, почему выбрали её. «Kafka, потому что нужна высокая пропускная способность и сохранение порядка сообщений в партиции» — правильный ответ. «Kafka, потому что все используют» — нет.

Можно ли пользоваться заметками на онлайн-секции? 

Технически можно, но не стоит. Интервьюер видит, когда вы читаете с листа. Лучше держать каркас в голове и рисовать по памяти.

Что делать, если задача из незнакомой предметной области? 

Скажите об этом. «Я не работал с геоиндексами, но предполагаю, что здесь нужен геохеш или R-tree. Давайте рассуждать от требований». Честность плюс логика лучше, чем блеф.

Сколько задач достаточно прорешать перед собеседованием? 

Зависит от уровня. Для джуна хватит 5-7 задач, разобранных по каркасу. Для мидла — десяти-пятнадцати, включая задачи с высокой нагрузкой. Для сеньора — двадцати и больше, с акцентом на компромиссы и развитие системы. Но количество не заменяет глубину: одна задача, разобранная до конца, полезнее десяти поверхностных.

Схему на доске стирают через минуту после окончания секции. А привычка смотреть на систему и задавать себе вопросы — где узкое место, что произойдёт при отказе, почему здесь эта база — остаётся. Она пригодится и на работе, и в пет-проектах, и в следующих собеседованиях.

Работодатель ищет инженера, с которым можно вместе разобраться в незнакомой задаче. Умение задавать вопросы и объяснять выбор здесь значит больше, чем знание конкретной технологии. Остальное можно добрать на месте.

Советуем почитать

Как правильно решать задачи на LeetCode: способы с ИИ и без — как готовиться к алгоритмической секции, которую статья противопоставляет system design: уровни задач, разбор ограничений, типичные ошибки.

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

Нормализация базы данных: 1НФ, 2НФ, 3НФ на примерах — как не дублировать данные и где нормализацию сознательно нарушают ради чтения (сентябрь 2026). Пригодится на шаге «Модель данных».

MySQL на собеседовании: вопросы junior и middle — JOIN, индексы, транзакции и уровни изоляции. Вопросы, которые задают вокруг секции system design.

Паттерны проектирования в программировании — порождающие, структурные и поведенческие паттерны с примерами на Python, плюс предупреждение не усложнять простые задачи.