План вместо паники
У задачи нет единственно верного ответа — жмёшь ⌥↩, и в «Подсказке» появляется структура: требования, нагрузка, компоненты, узкие места. Каждый пункт раскрываешь своими словами.
Сценарий
System design собеседование: каркас ответа раньше, чем ты начнёшь говорить
«Спроектируй ленту новостей» — и на секунду в голове пусто: вопрос открытый, начать можно откуда угодно. Vizir слышит задачу и сразу показывает каркас: требования → оценка нагрузки → компоненты → узкие места. Ты ведёшь рассуждение сам, вслух и своими словами, а оверлей держит план перед глазами и подхватывает каждый follow-up. Так системный дизайн интервью превращается из лотереи в управляемый разговор.
Как это выглядит
Пример по репликам
Вот как это выглядит: открытая задача дизайна, каркас в «Подсказке» и follow-up про масштаб.
ИнтервьюерСпроектируй ленту новостей — как в соцсети. С чего начнёшь?
VizirПодсказка → «Начну с требований: сколько активных пользователей и чего больше — чтения или записи. Прикину нагрузку в запросах в секунду. Дальше компоненты: балансировщик, кэш, база с шардированием и очередь, чтобы разносить посты подписчикам. И сразу назову узкие места.»
ТыСначала требования и оценка нагрузки, потом разложу на компоненты и отмечу узкие места.
ИнтервьюерОкей, 50 миллионов активных в день. Как fan-out переживёт пик?
VizirПодсказка → «Запись пущу через очередь, чтобы сгладить пики. Для аккаунтов с миллионами подписчиков переключусь с доставки при записи на сборку ленты при чтении, а горячие ленты закэширую — иначе очередь не разгребётся.»
ТыБуферизую запись очередью, для миллионников — сборка при чтении плюс кэш горячих лент.
Что делает Vizir в этом сценарии
Твоя диаграмма — в контексте
Интервьюер показал схему или дал доку с требованиями — снимаешь ⌥C или отправляешь выделенный текст ⌥⇧C. Дальше Vizir рассуждает про твою систему, а не про абстрактную.
Масштабирование не застанет врасплох
«А что при ×10 трафика?» — Vizir слышит вопрос прямо из звонка и подсказывает следующий ход: шардирование, реплики, инвалидация кэша. Контекст разговора он держит сам.
Обоснуй каждый выбор
SQL или NoSQL, push или pull — на вопрос «почему так?» ⌥↩ даёт аргументы за и против. Решение остаётся твоим, но теперь оно звучит осознанно.
Формат
Как устроено это собеседование
Секция дизайна длится 45-60 минут и стоит отдельно от алгоритмов: её дают на senior и выше, а на middle заменяют дизайном API или схемы базы. Ведёт её сильный инженер или архитектор, рисуешь в Miro, Excalidraw или на доске внутри редактора — иногда вообще без картинки, голосом.
Требования, потом схема
Первые минут десять — требования: что система умеет и сколько выдерживает, какая задержка допустима, что важнее — доступность или строгая согласованность. Дальше оценка нагрузки, схема верхнего уровня, углубление в один-два компонента по выбору интервьюера и разговор про узкие места.
Молча рисуют схему
Начать чертить, не задав ни одного вопроса, — главная ошибка: проверяют как раз умение добывать требования. Дальше по частоте: список технологий без обоснования, ноль оценок нагрузки, молчание про узкие места и разбор одного сервиса на весь час.
Вопросы
Что спрашивают и как звучит подсказка
Пять постановок, которые дают чаще остального, и каркас, который в этот момент лежит в «Подсказке».
«Прикинь: сколько запросов в секунду и сколько данных за год?»
Подсказка даёт порядок счёта вслух: от активных пользователей к действиям в сутки, поделить на 86 400, пик считать как несколько средних. Округляй и говори «примерно» — ждут порядок величины, а не точную цифру.
«Спроектируй мессенджер: доставка, статусы «прочитано», история»
В каркасе постоянное соединение, шлюз соединений, очередь на доставку и раздельное хранение переписки и метаданных. Уточни сам, нужны ли групповые чаты и офлайн-доставка: от этого меняется вся схема.
«Сделай бронирование так, чтобы одно место не продали дважды»
Подсказка ведёт от идемпотентного ключа заказа к удержанию места на время оплаты и уникальному ограничению в базе как последней линии. Скажи вслух, что здесь согласованность важнее доступности — это и есть ожидаемый вывод.
«Спроектируй ограничитель частоты запросов к публичному API»
Vizir перечислит алгоритмы — скользящее окно, дырявое ведро, токен-бакет — и подскажет, где держать счётчики, чтобы лимит работал на всех инстансах сразу. Добавь ответ 429 и заголовок с временем ожидания.
«Как хранить и раздавать файлы — видео, вложения, отчёты?»
Каркас простой: метаданные в базе, файлы в объектном хранилище, ссылки с коротким сроком жизни, раздача через CDN. Отдельно назови загрузку частями и то, что будет при обрыве.
Ещё один разбор
Сокращатель ссылок, по репликам
ИнтервьюерСпроектируй сокращатель ссылок. Ограничения задавай сам.
VizirПодсказка → «Профиль нагрузки: чтений в разы больше записей, значит ставка на кэш и CDN. Ключ — счётчик в base62: короткий и без коллизий, случайный пришлось бы проверять на занятость. Хранилище — key-value с шардированием по ключу. Редирект 302, если нужна аналитика переходов, 301 — если важнее скорость.»
ТыЧитают чаще, чем пишут — кэш перед key-value хранилищем, ключ счётчиком в base62, редирект 302, чтобы считать переходы.
ИнтервьюерГодится. Усложняю: ссылки с истекающим сроком.
Частые вопросы
Я ни разу не проходил системный дизайн интервью. Поможет?
Да. Каркас появляется до того, как ты начал отвечать, и ведёт по шагам: требования, нагрузка, компоненты, узкие места. Держать методологию в голове не обязательно — достаточно вести разговор.
Vizir поймёт схему, которую рисуют в Miro или Excalidraw?
Да. Снимаешь её ⌥C — скрин уходит нейросети вместе с контекстом разговора, и подсказки строятся вокруг твоей архитектуры.
А если интервьюер уведёт в сторону — например, в консистентность данных?
Vizir слышит каждый поворот разговора и подсказывает по ходу: репликация, кворумы, CAP — то, что уместно именно сейчас, без повторного ввода условия.
На следующий system design приходи с планом
3 дня и 30 минут речи бесплатно — карта не нужна. Поставь Визиря заранее и прогони пробное интервью: каркас, follow-up'ы, всё как вживую.