Ваш конспект

Системное проектирование (System Design) на собеседовании: фреймворк для успеха

Ключевые тезисы:

• System Design — сложная и опасная секция собеседования, где многие кандидаты терпят неудачу.
• Основные подводные камни: строгое ограничение по времени, минимальные входные данные и нереалистичные условия задачи.
• Ключ к успеху — использование чёткого фреймворка (поэтапного подхода), который помогает структурировать мысли и время.
• Главная цель — оставить после себя понятный, читаемый и обоснованный артефакт (схему решения).

Основные сложности секции

1. Время — на всё про всё обычно ~1 час. Нужно успеть спроектировать, презентовать и обосновать решение.
2. Минимум данных — интервьюер даёт лишь общую тему (например, «спроектируйте YouTube»). Проявлять инициативу в выяснении требований — ваша задача.
3. Нереалистичные условия — будут заданы огромные масштабы (миллиарды пользователей, петабайты данных). Условия часто уточняются по ходу беседы.

Фреймворк для прохождения

1. Сбор требований

Цель: чётко понять и очертить границы системы.

• Функциональные требования: Выясните, что должна делать система.
  • Пример для задачи «Подача объявления»: Что такое объявление? (заголовок, описание, картинки). Можно ли его удалять/деактивировать?
  • Важно: Не переусложняйте! Отсекайте «интересные», но необязательные фичи (лайки, сложная авторизация), чтобы не терять время и не повышать сложность.
  • Совет: На свои же уточняющие вопросы давайте быстрые и простые ответы (например, «ограничим заголовок 255 символами, 10 картинок»). Всё записывайте.
• Нефункциональные требования: Выясните, как система должна это делать.
  • Спросите про: нагрузку (RPS), количество пользователей, рост данных за N лет, объём хранимой информации.

2. Прикидочные расчёты

Цель: оценить порядки величин.

• Делайте очень грубые расчёты (π ≈ 3).
• Округляйте числа для удобства (5.45 Кб → 5 Кб).
• Используйте степени десятки (10³, 10⁶) вместо точных значений (1024).
• Пример: Объявление с 8-9 полями ≈ 5-6 Кб. Дальше перемножайте на количество объявлений.

3. Выделение доменов и High-Level API

Цель: разбить систему на крупные логические блоки перед тем, как рисовать схему.

• Выделите домены по глаголам из требований.
  • Пример: Работа с объявлением (создание, получение), Медиа (картинки), Поиск.
• Набросайте верхнеуровневое API для каждого домена (например, POST /ads, GET /ads/{id}).
  • Это черновик для понимания потоков данных. Не спорьте о REST-подходе или кодах ошибок на этом этапе.

4. High-Level Design (HLD)

Цель: создать архитектурную схему верхнего уровня.

• Начинайте с любого квадратика! Не бойтесь. На этом этапе нельзя сделать что-то «неправильное».
• Рисуйте квадраты (сервисы) и стрелки (потоки данных).
• Базовые компоненты для любой высоконагруженной системы:
  • Load Balancer (распределяет запросы).
  • Gateway / API Gateway.
  • Сервисы (ваши выделенные домены).
  • Очереди сообщений (Kafka, RabbitMQ).
  • Базы данных (квадрат «БД»).
  • Хранилище файлов (S3).
  • Кеш (Redis).
  • Поисковый движок (Elasticsearch).
  • CDN (для раздачи медиа).
• Результат: «Квадратура Малевича» — схема, с которой уже можно работать. Даже если собеседование закончится здесь, ваше решение выглядит конкурентоспособно.

5. Low-Level Design (LLD) и детализация

Цель: углубиться в ключевые компоненты.

• Детализируйте схему: Замените абстрактные «квадраты» на конкретные технологии (PostgreSQL, Kafka, S3, Redis).
• Фокусируйтесь на том, что знаете хорошо.
• Прорабатывайте сложные вопросы: Например, как хранить огромный объём объявлений?
  1. Рассмотрите варианты: PostgreSQL, Cassandra, MongoDB.
  2. Аргументируйте выбор: «Я не знаю MongoDB, поэтому не буду её рассматривать. Выберу между PostgreSQL и Cassandra».
  3. Обсудите компромиссы: «Выберем PostgreSQL с шардированием по ID. Плюс: равномерное распределение. Минус: сложный поиск всех объявлений автора (но эту проблему решим позже)».
• Критически важно: Не пытайтесь казаться умнее, чем вы есть. Не обсуждайте незнакомые технологии — высок риск ошибки.

6. Защита решения

Цель: ответить на вопросы и «поштормить» систему.

• Интервьюер будет задавать каверзные вопросы: «А если упадёт дата-центр?», «Как инвалидируется кеш?».
• Отстаивайте свой выбор, но будьте готовы к дискуссии.
• Идите от простого: сначала докажите работоспособность базового решения.

Критерии оценки интервьюером

1. Чёткое понимание границ задачи (умение не уходить в «шизотерику»).
2. Полнота и качество сбора требований.
3. Понимание, зачем и для кого создаётся система.
4. Умение аргументировать свой выбор и вести конструктивный спор.
5. Читаемость и аккуратность итоговой схемы (артефакта).
6. Умение вести интервью (не теряться, направлять беседу, пресекать затяжные споры).

Ключевые лайфхаки и выводы

• Рисуйте микросервисы, а не монолит. Сразу закладывайте горизонтальную масштабируемость.
• Для высоконагруженных систем сразу добавляйте в схему кеш (Redis).
• Для работы с медиа сразу добавляйте S3 и CDN.
• Начинайте проектирование с одного дата-центра. Масштабирование на несколько ЦОД можно дорисовать позже.
• Аккуратность — краеугольный камень. Подписывайте компоненты, рисуйте понятные стрелки, раскрашивайте домены.
• Избегайте циклических зависимостей между сервисами.
• Не отдавайте инициативу надолго — ведите интервью сами.
• Главный принцип: НЕ ПЕРЕУСЛОЖНЯЙТЕ. Не говорите о том, чего не знаете. Воюйте только на том поле, где чувствуете силу.