Урок

Что проверяют и как построить ответ

Чем этот собес отличается от алгоритмов

На алгоритмической задаче есть правильный ответ: код либо проходит тесты, либо нет. На System Design единственного правильного ответа нет. Попросят «спроектируй Twitter», и десять сильных инженеров нарисуют десять разных схем, и все десять могут получить оффер.

Представь, что ты архитектор, а заказчик говорит: «Постройте мне дом». Плохой архитектор сразу рисует трёхэтажный особняк с бассейном. Хороший сначала спрашивает: сколько человек будет жить? какой бюджет? какой климат? Дом для семьи из трёх человек в Сочи и общежитие на 500 студентов в Норильске — совершенно разные проекты.

На собесе ты тот самый архитектор. Интервьюер смотрит не на «красивую картинку», а на то, как ты думаешь.

Что проверяют	Как это выглядит на деле
Умение прояснить задачу	Задаёшь вопросы, а не бросаешься рисовать
Работа с числами	Оцениваешь нагрузку и объём данных
Компромиссы (trade-offs)	«Можно так, можно эдак, выбираю X, потому что…»
Структурность	Двигаешься по шагам, не прыгаешь хаотично
Коммуникация	Думаешь вслух, слушаешь подсказки

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

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

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

Шаг	Время	Что делаешь
1. Требования	5–7 мин	Функциональные и нефункциональные
2. Оценка нагрузки	3–5 мин	RPS, объём данных, пики
3. API	3–5 мин	Ключевые эндпоинты
4. Модель данных	3–5 мин	Сущности, связи, выбор БД
5. Общая схема	5–7 мин	Простая рабочая архитектура
6. Узкие места	10–15 мин	Углубляешься туда, где больно
7. Масштаб и отказы	5 мин	Что сломается и как переживём

Пройдём по шагам.

1. Требования

Функциональные описывают, что система делает: «пользователь публикует пост», «видит ленту друзей». Нефункциональные описывают, какой она должна быть: сколько пользователей, допустимая задержка, что важнее — доступность или строгая согласованность.

Как звучит: «Давай я уточню скоуп. Нужны ли нам лайки и комментарии или фокусируемся на публикации и ленте? Сколько у нас активных пользователей в день? Допустимо ли, если пост появится у друзей с задержкой в пару секунд?»

2. Оценка нагрузки

Здесь не нужна точность, нужен порядок величин. Пример расчёта:

Параметр	Расчёт	Итог
Активных в день (DAU)	дано	10 млн
Запросов на пользователя	~20 в день	200 млн/день
Средний RPS	200 млн / 86 400 с	≈ 2 300
Пиковый RPS	× 3	≈ 7 000

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

3–4. API и модель данных

Набросай 2–3 главных эндпоинта, не больше:

POST /posts          {"text": "..."}
GET  /feed?cursor=abc

Потом назови основные сущности (User, Post, Follow) и объясни выбор хранилища: «Связи между пользователями реляционные, начну с PostgreSQL».

5. Общая схема: начни с простого

Сначала нарисуй самую простую систему, которая работает:

Отправная точка: клиент → сервер → база

Это не наивность, а осознанный приём. Ты показываешь, что понимаешь суть, и получаешь базу, которую можно улучшать.

6–7. Узкие места, масштаб, отказы

Теперь вспоминаешь свои 7 000 RPS и спрашиваешь себя: где заболит? Один сервер станет узким местом, база захлебнётся от чтений. Схема эволюционирует:

После анализа нагрузки: балансировщик, несколько серверов, кэш

Каждый новый блок обязательно сопровождай компромиссом: «Кэш снимет нагрузку с базы, но появится риск устаревших данных. Для ленты это приемлемо». Про отказы рассуждай так: «Если упадёт один API-сервер, балансировщик уведёт трафик на второй. Если упадёт основная база, переключимся на реплику, но потеряем несколько последних секунд записи».

Интервьюер часто сам подскажет, куда копать: «А что будет с популярными пользователями?» Это не ловушка, а приглашение. Хватайся за подсказку.

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

Сразу рисовать микросервисы, Kafka и Kubernetes. Это выглядит как попытка впечатлить, а не решить задачу. Сложность добавляют только тогда, когда её оправдывают числа.
Не спросить про нагрузку. Без цифр любое решение висит в воздухе: ты не можешь объяснить, зачем тебе шардирование или почему хватит одной базы.
Молчать. Самая дорогая ошибка. Интервьюер не читает мысли: молчание засчитывается как «не знает». Даже сомнения проговаривай: «Тут вижу два варианта, сейчас взвешу…»
Утонуть в одной детали. 20 минут обсуждать индексы и не дойти до общей схемы. Следи за часами по каркасу.
Называть решение без цены. «Возьму NoSQL» — слабо. «Возьму NoSQL ради горизонтального масштабирования, но откажусь от сложных JOIN» — сильно.

Главное

У тебя теперь есть скелет, который подходит под любую задачу: требования → цифры → API → данные → простая схема → узкие места → отказы. Ты не обязан знать всё на свете. Нужно вести разговор структурно, думать вслух и честно называть компромиссы. Именно этому и посвящены следующие уроки курса.