System Design:

7 шагов, которые помогут пройти собеседование

и понять архитектуру

Системный дизайн — это секция, на которой заваливаются даже сеньоры.
Часто не из-за нехватки знаний, а потому что не знают, что от них реально ждут.

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

Что почитать и посмотреть

по системному дизайну?

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


Разделено по формату: читаешь → смотришь → пробуешь.


Можно идти последовательно, а можно выбрать то, что лучше ложится на текущий уровень и формат восприятия.

1. Читаю — статьи, книги, конспекты.

System Design Interview An Insider’s Guide – Alex Xu
Базовая книга для подготовки к прохождению системного дизайна. В ней описана стандартная структура прохождения интервью и разобрано несколько примеров дизайна систем от сбора требований до финального решения. Книга простая, понятная и подойдёт даже начинающим.
Designing Data-Intensive Applications — Martin Kleppmann
Книга, которую стоит читать медленно и вдумчиво. Много примеров, как работают современные системы. Основной фокус – проектирование высоконагруженных баз данных. Для среднего и продвинутого уровня.
Distributed Systems – M. van Steen and A.S. Tanenbaum
Книга продвинутого уровня для тех, кто хочет научиться проектировать надёжные и отказоустойчивые распределённые системы. Рекомендую к изучению даже вне контекста интервью по системному дизайну.
Отличная статья, подробно показывающая процесс прохождения системного дизайна в Яндексе.
Огромная и довольно подробная методичка по различным аспектам построения больших, высоконагруженных систем. Покрывает многие вопросы: от кеширования до протоколов коммуникации.
Большой и достаточно обстоятельный гайд о том, как проходить системный дизайн. Подойдёт в качестве шпаргалки перед самим собеседованием, чтобы освежить в памяти структуру.

2. Смотрю — видео, доклады, визуальные объяснения.

Подробнейший курс о подготовке к прохождению системного дизайна от нанимающих менеджеров Google. По моим ощущениям покрыты все темы, которые могут понадобиться при прохождении собеседования.
Пример проектирования архитектуры сервиса по доставке еды (типа Яндекс.Еда). Хороший пример того, как нужно работать на интервью по системному дизайну.
Запись live-интервью с конференции ArchDays 2022, где разбирается задача проектирования системы бронирования отелей а-ля Booking. Отличительная особенность: разбор сделан в формате настоящего интервью, поэтому можно подсмотреть, как оно проходит.
Запись live-интервью с конференции ArchDays 2023, где разбирается задача проектирования системы А/В тестирования гипотез. Задача отличается тем, что домен довольно сложный и не знаком собеседованию. Отличный пример того, как нужно себя вести в таких ситуациях.
Практически классическая задача проектирования сервиса с большим объёмом файлов и огромным трафиком. Полезна для разбора в любом случае, потому что базовые принципы её решения легко переносятся на другие задачи.
Проектирование высоконагруженной гео-системы. Очень пригодится, если никогда не работали с гео, закрывает множество нюансов и тонкостей. Работа с гео также может встретиться в задачах, поэтому разобраться стоит.

3. Применяю — репозитории с задачами, симуляторы собесов, тренажёры.

Внушительный набор задач для самостоятельного проектирования. Достаточно просто нажать кнопку Do One. Рекомендую самостоятельно усложнить нефункциональные требования, чтобы решать было интереснее.
Список хороших архитектурных задач от автора книг по архитектуре. Выбирайте любую и решайте.
Аналог LeetCode для системного дизайна. Уже сейчас есть почти 30 задач и готовится ещё несколько. Задачи и требования к ним взяты с реальных систем.
Mock interview
Отличный способ подготовиться к прохождению системного дизайна – провести тестовое собеседование с реальным человеком. Найдите себе наставника на сервисах по поиску менторов и пройдите собеседование. Задача не должна быть вам известна. Это позволит в безопасной обстановке отработать свои навыки и найти слабые места.
Разбор задачи от эксперта
Решив какую-либо задачу по архитектуре, вы можете запросить её разбор у ментора. Он даст вам обратную связь, расскажет, что можно улучшить и на какие детали стоит обратить внимание.

7 шагов, которые помогут пройти собеседование по System Design

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

2. Уточни нефункциональные требования
Спросите про доступность, масштабируемость, нагрузку, допустимые задержки. Это формирует технический контекст.

3. Нарисуй high-level архитектуру — и только потом детали
Покажи главные блоки, каналы коммуникации и точки масштабирования. Подробности потом.

4. Обозначь узкие места и компромиссы
Важно не только предложить решение, но и показать, что ты видишь потенциальные проблемы и умеешь их устранять.

5. Проговори, как бы ты тестировал и мониторил систему
Про наблюдаемость часто забывают — а это критически важно на реальной нагрузке.

6. Обоснуй выбор технологий
Говори не “я бы взял Kafka”, а “Kafka подойдёт, потому что…”. Интервьюер смотрит на логику, не на модные названия.

7. Не забудь про эволюцию
Покажи, как бы ты начал с MVP и как система может масштабироваться по мере роста нагрузки и команды.

5 ошибок, из-за которых сливаются даже опытные инженеры

Ошибки, которые я слышал десятки раз — и которые снижают впечатление даже от сильного кандидата.

❌ Сразу начинают рисовать архитектуру
Проблема: нет контекста, непонятно, зачем система вообще нужна.
Что делать: начать с уточнения требований и целей бизнеса.

❌ Слишком много деталей на старте
Проблема: кандидат уходит в выбор баз, кэшей и очередей ещё до общей схемы.
Что делать: сначала показать high-level архитектуру, потом углубляться.

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

❌ Боятся делать предположения
Проблема: ждут, что интервьюер сам всё скажет.
Что делать: формулировать допущения и озвучивать их. Это плюс, а не минус.

❌ Не озвучивают компромиссы
Проблема: решение звучит “идеально”, но не реалистично.
Что делать: говорить, где тонкие места, и как ты бы это улучшал.

Что могут спросить на секции по системному дизайну?

5 типичных задач, которые часто встречаются на интервью.

Главное — не запоминать “правильное решение”, а тренировать ход мысли.

Проектирование URL shortener (аналог bit.ly)

Чего ждут: простая архитектура, high-level план, как масштабировать.
Чат/мессенджер с офлайн-доставкой и пушами

Чего ждут: надёжность, очередь сообщений, хранение статуса.
Система бронирования (например, Booking)

Чего ждут: как справляться с гонкой за слоты, транзакционность, consistency.
Проектирование URL shortener (аналог bit.ly)

Чего ждут: простая архитектура, high-level план, как масштабировать.
⚠️ На собеседовании не ищут “идеального” решения.
Смотрят на то, как ты рассуждаешь, задаёшь вопросы, приоритизируешь. Твоя задача — показать это.

Мини-разбор: как думать на собеседовании по системному дизайну

Задача: спроектировать простую систему коротких ссылок (аналог bit.ly)

ШАГ 1: ПОНЯТЬ ЗАДАЧУ И ОПРЕДЕЛИТЬ МАСШТАБ РЕШЕНИЯ
На интервью по проектированию ИТ-систем специально дают задачи, допускающие свободную трактовку. Чтобы разработать хорошо продуманную систему, необходимо задавать уточняющие вопросы.

Типичные сценарии использования:
  1. Сокращение URL-адресов: дается длинный URL-адрес → возвращается намного более короткий URL-адрес.
  2. Перенаправление URL-адресов: дается сокращенный URL-адрес → пользователь перенаправляется к исходному URL-адресу.
  3. Высокая доступность, масштабируемость и устойчивость к сбоям.
ШАГ 2: ПРЕДЛОЖИТЬ ОБЩЕЕ РЕШЕНИЕ И ПОЛУЧИТЬ СОГЛАСИЕ
Конечные точки API

Сервису сокращения URL-адресов нужны две основные конечные точки:
  1. Сокращение URL-адреса.
  2. Перенаправление URL-адреса.
Сокращение URL-адресов

Допустим, сокращенный URL-адрес выглядит как www.tinyurl.com/{hashValue}. Чтобы его получить, мы должны найти функцию fx, которая привязывает длинный URL-адрес к hashValue.

К функции хеширования предъявляются следующие требования:
  1. Каждое значение longURL должно иметь один хеш hashValue;
  2. Каждое значение hashValue должно указывать обратно на longURL.
ШАГ 3: ПОДРОБНОЕ ПРОЕКТИРОВАНИЕ
Модель данных

Нам нужно хранить <shortURL, longURL>, в начале это лучше делать с использованием реляционной базе данных. Схема таблицы БД состоит из трех столбцов: id, shortURL, longURL.

Функция хеширования

Функция хеширования используется для получения из длинного URLадреса хеша — hashValue. hashValue состоит из символов [0-9, a-z, A-Z], число которых равно 10 + 26 + 26 = 62. Чтобы определить длину hashValue, нужно найти наименьшее n, при котором 62^n ≥ 365 миллиардов. Судя по этим прикидкам, система должна поддерживать до 365 миллиардов URL-адресов

Распространенным методом сокращения URL-адресов является преобразование значения в другую систему счисления. Поскольку для hashValue используется набор из 62 символов, мы выберем алгоритм base62.

High-level архитектура
  1. API-слой → сервис генерации → база данных.
  2. Редирект-сервис → кэш → база.
  3. Аналитика пишется асинхронно (через очередь).
  4. Для хранения можно начинать с SQL, позже перейти на распределённую key-value базу.
  5. Используем кеш (Redis) перед базой для скорости.
ШАГ 4: ПОДВЕДЕНИЕ ИТОГОВ
Если в конце интервью остается время, можно обсудить дополнительные вопросы.

  1. Ограничитель трафика. Мы можем столкнуться с потенциальной проблемой безопасности: злоумышленники могут послать чрезмерно большое количество запросов на сокращение URL-адреса. Ограничитель трафика помогает фильтровать запросы с учетом IP-адреса или других правил.
  2. Масштабирование веб-серверов.
  3. Масштабирование базы данных.
  4. Аналитика. Данные играют все более важную роль в успехе бизнеса. Интеграция аналитической системы в сервис для сокращения URLадресов поможет получить такие ценные сведения, как количество пользователей, перешедших по ссылке, точное время перехода и т. д.
  5. Доступность, согласованность и надежность. Эти характеристики являются ключом к успеху любой крупной системы.
⚠️ Главное — не “угадать правильный ответ”, а показать, что умеешь задавать правильные вопросы и думать системно.

Что хочет услышать интервьюер —

взгляд изнутри

Я сам провожу собеседования на системный дизайн, и честно — мне не нужен “идеальный кандидат, который всё знает”. Что для меня важнее:

1. Ты умеешь мыслить на уровне системы
Не просто знаешь фреймворки, а понимаешь, как разные компоненты работают вместе.

2. Ты говоришь вслух
Ты не молчишь и не “угадываешь правильный ответ”, а озвучиваешь свои допущения, ходы мысли, сомнения. Это очень ценно.

3. Ты осознаёшь компромиссы
Не пытаешься сделать идеально. Умеешь объяснить, что выбрал решение, потому что оно проще/быстрее/надёжнее в конкретной ситуации.

4. Ты структурируешь ответ
Когда человек начинает “с проблемой”, потом говорит “архитектура вот такая”, потом “технологии вот эти, потому что...”, — это производит очень сильное впечатление.

5. Ты показываешь реальный опыт
Если ты делал похожие системы — расскажи. Но даже если не делал, покажи, что умеешь логически рассуждать. Это плюс.
💡 Это всё проверяется не за счёт “правильных решений”, а по тому, как ты строишь диалог и демонстрируешь мышление. И это можно натренировать.
📎 Если хочешь регулярно прокачивать хард-скиллы и уверенно чувствовать себя в техничке — оставайся в канале Ulshinblog про IT

Автор канала — Никита Ульшин, руководитель команды Highload разработки и интервьюер на секции системного дизайна.

В канале уже 50+ обзоров книг про IT, управление и мышление, обзоры материалов по system design, архитектуре высоконагруженных систем, базам данных и прочим техническим темам.