System Design собеседование: как готовиться и что спрашивают
System Design пугает сильнее алгоритмов, потому что тут нет правильного ответа. Просят спроектировать систему: сервис коротких ссылок, ленту, рекомендации, ML-сервис под нагрузкой. Готового решения не существует, и оценивают не его, а как вы думаете. Разберём, что именно проверяют и как вести разговор, чтобы не растеряться.
Как вести разговор: сначала требования
Главная ошибка кандидата, услышав «спроектируй сервис коротких ссылок», сразу кинуться рисовать базы и серверы. Так делать нельзя. Сначала уточняют требования: сколько пользователей ожидается, какие операции важнее, сколько живёт ссылка, нужна ли аналитика переходов, что критичнее, скорость или консистентность.
Хороший кандидат первые минуты задаёт вопросы, а не рисует. Это и проверяют в первую очередь: умение превратить размытую задачу в конкретную, прежде чем решать.
Оценка нагрузки
Дальше прикидывают масштаб, и это ждут от вас вслух. Например: сто миллионов новых ссылок в месяц, а переходов по ним примерно в сто раз больше. Из такой прикидки сразу следуют выводы: система на чтение нагружена сильнее, чем на запись, значит упор на кэш и быстрое чтение. Умение прикинуть порядок величины (capacity estimation) и сделать из него архитектурный вывод отличает предметный разговор от гадания.
Из чего собирают архитектуру
Когда требования и масштаб ясны, собирают решение из блоков и проговаривают путь запроса:
- Хранилище. Какая база под задачу: реляционная, ключ-значение, что где хранить.
- Кэш. Где поставить, что кэшировать, как инвалидировать. Для read-heavy систем это ключевое.
- Путь чтения и записи. Что происходит по шагам, когда пользователь создаёт короткую ссылку и когда по ней переходит.
- Контракт API. Какие эндпоинты, что принимают и возвращают.
Оценивают не знание модных технологий, а обоснованность выбора: почему именно эта база, зачем здесь кэш.
Отказоустойчивость
Секцию почти всегда заворачивают в сторону «а что, если сломается». Что будет при отказе одного узла, как система переживёт всплеск нагрузки, где точки отказа, как не потерять данные. Проговорить деградацию и запас прочности это признак зрелого инженера.
ML System Design
Если позиция про ML, добавляется свой пласт, где ломается больше всего народу:
- Batch против online инференса. Считать предсказания заранее пачкой или в реальном времени на запрос. Для ежедневных персональных рекомендаций часто хватает batch, для реакции на действие нужен online.
- Training-serving skew. Когда признаки на обучении считаются иначе, чем в проде, и модель тихо деградирует. Архитектурный приём против этого, общий код признаков или фичестор.
- Мониторинг дрейфа. Метки в проде часто приходят с задержкой (дефолт по кредиту виден через недели), поэтому качество модели мониторят косвенно, по дрейфу входных данных, а не только по финальной метрике.
Как готовиться
System Design ставится разбором готовых кейсов и повторением каркаса: требования, нагрузка, блоки, отказы. Читать статьи про архитектуру полезно, но без прогонки собственных решений на собесе будет ступор.
В Сеньорчике для этого есть отдельный режим «Систем-дизайн собес»: кейсы разбираются по шагам, от уточнения требований до оценки нагрузки и сборки архитектуры, с разбором на каждом. Есть и классический System Design, и ML System Design. Как устроена вся воронка собеседования в целом, разобрано в посте про технические вопросы. Начать можно бесплатно.