System design собеседование: структура ответа на 45 минут

Вам говорят: «Спроектируйте сервис сокращения ссылок», и дают пустую доску. Задача звучит просто, поэтому рука сама тянется рисовать квадратик «база данных». Через двадцать минут на доске шесть квадратиков, интервьюер спрашивает, сколько запросов в секунду выдержит эта схема, а вы этого ни разу не считали.

По AI-разборам собеседований пользователей Sobes систем-дизайн выходит самым трудным этапом: средняя успешность 52% против 61% у технических интервью. Задачи при этом бывают далеко не только про ленты и чаты. В банке есть, например, «Спроектируйте систему семантического поиска по корпоративной документации на 1М документов» и «Спроектируйте систему персонализированных рекомендаций товаров для маркетплейса». Выучить ответы на все варианты нельзя, зато можно выучить порядок, в котором строится любой ответ.

План на 45 минут

Из часа на саму задачу обычно остаётся минут сорок пять: остальное уходит на знакомство и ваши вопросы.

Границы условные. Если интервьюер на двадцатой минуте уводит вас в детали шардирования, идите за ним: он показывает, что хочет оценить.

Требования и нагрузка: первые десять минут

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

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

Вы сами предлагаете, что отрезать. Интервьюер видит, что вы умеете ограничивать задачу, а не пытаетесь спроектировать всё сразу.

Дальше цифры. Точность не нужна, нужен порядок величин, и считать его надо вслух:

Пусть создаётся 100 миллионов ссылок в месяц. В месяце примерно 2,6 миллиона секунд, получается около 40 записей в секунду. Читают ссылки гораздо чаще, чем создают. Возьму сто к одному: это 4 000 редиректов в секунду, в пике закладываю вдвое больше. За пять лет наберётся 6 миллиардов записей. Если на запись уходит полкилобайта, это около 3 терабайт.

Из этих трёх чисел следует половина решений. Запись мелкая, чтение доминирует, значит, нужен кэш перед хранилищем. 3 терабайта на один сервер ставить неудобно, значит, придётся говорить о шардировании.

API и данные

API пишите как сигнатуры, без лишних деталей:

POST /links        { url, ttl? }  ->  { code }
GET  /{code}       ->  302 Location: url

Модель данных здесь из одной таблицы: code, url, created_at, expires_at. Поиск всегда идёт по ключу, связей нет, поэтому подойдёт key-value хранилище или обычная реляционная база с шардированием по code. Назовите выбор и причину одной фразой, технологию без причины интервьюер не засчитает.

Отдельно скажите, откуда берётся code. Семь символов base62 дают около 3,5 триллиона комбинаций, для 6 миллиардов записей запас большой. Варианта генерации два: счётчик с кодированием в base62 или случайная строка с проверкой на коллизию. У счётчика нет коллизий, но коды предсказуемы и нужен общий источник номеров. Выберите один и объясните почему.

Схема

Теперь можно рисовать. Клиент, балансировщик, несколько экземпляров сервиса без состояния, кэш, хранилище. Проведите по схеме оба сценария вслух: что происходит при создании ссылки и что при переходе по ней.

Редирект: запрос приходит на любой экземпляр, он смотрит в кэш. Если код там есть, сразу отдаём 302. Если нет, идём в базу, кладём результат в кэш и отвечаем. Популярные ссылки почти всегда будут в кэше, до базы дойдёт малая часть чтений.

Проговорённый путь запроса полезнее лишних квадратиков: по нему видно, что схема работает, а вы понимаете, зачем в ней каждый элемент.

Узкие места и компромиссы

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

• Хранилище: шардирование по коду, реплики для чтения.
• Кэш: что будет, если он упадёт и весь поток пойдёт в базу.
• Генератор кодов: один счётчик на всех или диапазоны номеров, выданные каждому экземпляру.
• Одна «горячая» ссылка, по которой идёт половина трафика.

Компромиссы называйте прямо, с ценой:

Я отдаю 302, а не 301. Браузер не закэширует редирект, поэтому каждый переход придёт к нам. Нагрузка выше, зато можно считать статистику и отключить ссылку. Если статистика не нужна, 301 дешевле.

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

Типичные ошибки

• Рисовать с первой минуты. Без требований и цифр схему нечем обосновать, и её приходится перерисовывать.
• Молчать. Интервьюер оценивает рассуждение, а на доске его не видно. Тот же навык нужен на лайвкодинге, о нём есть статья «Лайвкодинг на собеседовании: что говорить вслух».
• Не считать нагрузку. Тогда кэш, шарды и очереди появляются «потому что так принято».
• Называть технологии без причины: Kafka, Redis, Cassandra в одном предложении и ни одного «потому что».
• Проектировать идеальную систему на миллиард пользователей, когда в требованиях десять тысяч.
• Защищать первое решение до конца. Если интервьюер нашёл дыру, согласитесь и перестройте схему.

Если спрашивают про технологию, с которой вы не работали, не изображайте опыт. Как рассуждать в такой ситуации, показано в статье «Не знаю ответ на собеседовании». О месте систем-дизайна среди остальных этапов коротко рассказано в статье про техническое собеседование.

Как тренироваться

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

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