System Design пугает открытостью: нет единственно верного ответа, зато легко утонуть в деталях. Хорошая новость — интервьюер оценивает не «идеальную» схему, а ход мысли: умеете ли вы работать с требованиями, прикидывать масштаб и обосновывать выбор технологий. Вот пять приёмов, которые держат разговор в русле, и общий шаблон, по которому стоит вести всю секцию.
1. Сначала требования
Не бросайтесь рисовать сервисы. Сначала разделите требования на два вида. Функциональные — что система должна делать (например, для ленты: публикация постов, подписки, выдача ленты). Нефункциональные — какой она должна быть: доступность, латентность, консистентность, масштабируемость.
Договоритесь о рамках: что в скоупе, а что нет. Уточните аудиторию и нагрузку — сколько пользователей, соотношение чтения и записи, требования к времени ответа. Эти вопросы в начале — первое, что отличает сильного кандидата от того, кто сразу лезет в детали.
2. Считайте на салфетке
Прикиньте порядок величин — это показывает инженерное мышление и помогает осознанно выбирать между кэшем, репликами и шардированием. Считать можно грубо, главное — правильный порядок.
Пример: 10 млн активных пользователей в день, каждый делает ~10 действий → около 100 млн запросов в день, это примерно 1000–1200 RPS в среднем и в 2–3 раза больше в пик. Если каждая запись весит ~1 КБ и их 100 млн в день — это ~100 ГБ в сутки, ~36 ТБ в год. Такие цифры сразу подсказывают: одна база не потянет, нужны шардирование и кэш горячих данных.
3. От простого к сложному
Начните с минимальной работающей схемы: клиент → сервис → база. Затем усложняйте по мере появления узких мест: добавили кэш (Redis) под горячее чтение, реплики чтения под рост нагрузки, очередь (Kafka/RabbitMQ) под асинхронные задачи, шардирование и CDN — когда упёрлись в объём и географию.
Не проектируйте сразу на гугл-масштаб, если этого не просили. Преждевременная сложность читается как неумение расставлять приоритеты. Каждое усложнение вводите как ответ на конкретную проблему, а не «потому что так модно».
4. Проговаривайте trade-offs
Любое решение — компромисс. Consistency против availability (теорема CAP), латентность против стоимости, SQL против NoSQL, синхронная обработка против асинхронной. Интервьюер оценивает не «правильный» выбор, а то, как вы его обосновываете.
Формулируйте вслух: «возьму такой-то подход, потому что здесь важнее X, и готов пожертвовать Y». Например: «для ленты допустима eventual consistency — читателю не критично увидеть пост на секунду позже, зато мы выигрываем в доступности». Это ровно та инженерная зрелость, которую ищут.
5. Держите структуру
Под давлением таймера легко забыть про целые пласты. Держите в голове чек-лист компонентов: балансировщик нагрузки, кэш, база (и её масштабирование), очередь, CDN, мониторинг, безопасность. Даже если не успеваете углубиться во всё — обозначьте, что помните про эти аспекты.
System Design — лишь одна из секций собеседования. Как собрать весь звонок целиком, мы разобрали в гайде «Как пройти техническое собеседование».
Общий шаблон ответа
Чтобы не растекаться, ведите секцию по одному и тому же маршруту — он работает почти на любой задаче:
1. Уточнить требования (функциональные и нефункциональные). 2. Прикинуть нагрузку и объём данных. 3. Описать API (основные эндпоинты). 4. Набросать модель данных. 5. Нарисовать высокоуровневую схему. 6. Углубиться в 1–2 узла по просьбе интервьюера. 7. Найти узкие места и предложить, как их расшить.
Если держать этот скелет в голове, даже незнакомая задача перестаёт быть пугающей: вы всегда знаете, какой шаг следующий.
Пример: сокращатель ссылок
Пройдём по шаблону на классической задаче «спроектируйте сервис коротких ссылок» (как bit.ly). Требования: по длинному URL выдать короткий и по короткому — редиректить на длинный; чтений много больше, чем записей; критична низкая латентность редиректа.
Оценка: допустим, 100 млн новых ссылок в месяц и в 100 раз больше переходов — это тысячи RPS на чтение, значит без кэша не обойтись. API: POST /shorten и GET /{code}. Модель данных: code → long_url, ключ — сам короткий код. Схема: генерируем код (счётчик в base62 или хеш), пишем в базу, горячие ссылки держим в Redis; редирект сначала бьёт в кэш. Узкие места: рост базы решаем шардированием по коду, всплески чтения — репликами и кэшем, коллизии кодов — проверкой при вставке.
Обратите внимание: мы ни разу не «угадывали идеальную архитектуру», а выводили её из требований и нагрузки. Именно это и оценивают.
Когда что брать
Половина уверенности на секции — знать, каким компонентом закрывается какая боль. Короткая шпаргалка:
Кэш (Redis) — когда чтений много больше записей и данные можно отдавать чуть устаревшими. Реплики чтения — когда упёрлись в нагрузку на чтение, но данные должны быть свежими. Очередь (Kafka/RabbitMQ) — когда задачу можно выполнить асинхронно (отправка писем, обработка загрузок) и сгладить пики. Шардирование — когда данные не влезают в одну базу. CDN — для статики и географически распределённых пользователей. Балансировщик — как только сервисов становится больше одного.
Ключевое — не перечислить всё подряд, а привязать каждый компонент к конкретной проблеме из ваших же требований.
Типичные ошибки
На чём чаще всего заваливают секцию: сразу рисуют детали, не уточнив требования; переусложняют — тащат микросервисы и Kafka туда, где хватило бы одной базы; молчат, не проговаривая рассуждение; забывают про нефункциональные требования — мониторинг, отказоустойчивость, безопасность.
И главная ошибка — искать «правильный» ответ. Его нет. Интервьюер оценивает, как вы движетесь от требований к решению и как обосновываете компромиссы, а не совпадение с эталоном в его голове.