System design отделяет «могу закрыть тикет» от «могу спроектировать кусок системы и назвать цену решения». Код здесь почти не пишут. Смотрят, умеете ли вы уточнить требования, оценить масштаб, выбрать хранилище и очередь не из моды, а из паттерна доступа, и вовремя сказать, где система сломается. Правильного ответа как у задачи на сумму массива нет. Есть ход мысли, который можно обсуждать.

Ниже — кому это вообще светит, универсальный каркас, два прохода на классических постановках (сокращатель ссылок и сервис уведомлений) и как готовиться с нуля за несколько недель, не заучивая чужие схемы из блога. Соседние этапы: интервью backend и live coding. Общий каркас вопросов — вопросы на собеседовании.

Коротко:

  • Не рисуйте коробки, пока не зафиксировали функциональные и нефункциональные требования и порядок цифр по нагрузке.
  • Каркас один: требования → масштаб → API → данные → схема → одно узкое место глубоко → отказ.
  • Молчание хуже простой схемы. Компромисс надо назвать вслух: цена кэша, цена очереди, цена шарда.
  • Junior видит упрощённый вариант. Middle+ и платформа — почти всегда. Смотрите слоты в backend и senior.
  • Готовьте 8–10 задач одним каркасом, а не 40 картинок из интернета.

Что проверяют на самом деле

Умение не угадать «эталонную архитектуру Twitter», а вести разговор: что важно продукту, сколько примерно пишут и читают, где можно быть неточным, где нельзя потерять запись. Интервьюер часто сам сужает задачу. Если вы уже нарисовали Kafka, Kubernetes и пять баз, а нагрузка — сотни запросов в минуту, вы провалили калибровку, не «недостаточно энтерпрайза».

Коммуникация здесь часть оценки. То же правило, что на behavioral: ясный вклад, граница, урок. Только объект — система, не конфликт. Самопрезентацию на design-раунд не тратьте — её уже слышали. Рассказ о себе оставьте скринингу.

Кому и в каком виде это встречается

Backend, fullstack, платформенные инженеры middle+, техлиды — почти всегда. Junior — реже и короче: «нарисуйте API и таблицу для объявлений». Если в вакансии нет слова design, навык всё равно всплывает в «как устроен ваш сервис». Тогда готовьте свою схему, не shorten URL на память.

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

Универсальный каркас ответа

  1. Требования. Что система должна делать. Что сознательно не делает в этой версии. Нефункциональное: задержка, доступность, консистентность, срок хранения, регуляторика, если всплыла.
  2. Масштаб. Порядок пользователей, RPS чтения и записи, размер объекта, рост за год. Не точная бухгалтерия — порядок, от которого зависит, нужна ли очередь и шард.
  3. API. Два-четыре метода. Контракт фиксирует границы лучше, чем облако из сервисов.
  4. Данные. Что ключ, какие запросы, TTL. Реляционка, ключ-значение, очередь, файловое хранилище — под доступ, не под резюме.
  5. Схема. Клиент, шлюз, сервис, база, кэш, очередь, воркер. Один путь счастливый, один путь отказа.
  6. Глубокое место. Одно на выбор интервьюера или ваше: шарды, кэш и его враньё, идемпотентность, фан-аут ленты, ретраи.
  7. Узкие места. Что умрёт первым при x10. Что мониторите. Как деградируете.

Не пропускайте пункт 1 из желания «уже показать уровень». Большинство провалов — решение не той системы.

Цифры масштаба можно и нужно брать как гипотезу. Скажите: «считаем миллион активных в день, чтение к записи 100 к 1, объект ссылки мелкий — если порядок другой, схема сдвинется вот здесь». Интервьюер поправит. Молчаливое рисование «как в статье» без порядка величины почти всегда приводит к лишней очереди и лишнему шарду. Если цифр совсем нет, предложите две ветки: малая нагрузка — одна база и кэш; большая — вот что добавим первым.

Строительные блоки, без которых каркас пустой

Балансировщик и несколько инстансов приложения. Репликация чтения. Шард, когда один узел больше не держит данные или запись. Кэш: что ключ, кто инвалидирует, что будет, если кэш соврал. Очередь: зачем (пик, повтор, развязка HTTP), цена (задержка, порядок, poison). Идемпотентность ключом. Таймаут и повтор. Идемпотентный консьюмер. «Доступность против строгой согласованности» — одной фразой на вашем кейсе, не лекцией про CAP на доске.

Этого набора хватает на большинство учебных задач. Не добавляйте сервис «просто чтобы был». Каждая коробка должна отвечать на вопрос из требований.

Проход 1. Сокращатель ссылок — каркас, не эталон из блога

Постановка: «спроектируйте сервис коротких ссылок». Не копируйте чужую картинку. Пройдите каркас вслух.

Сначала зафиксирую: пользователь даёт длинный URL, получает короткий код, по коду редирект. Нужны ли свои домены, аналитика кликов, срок жизни, кастомный алиас, авторизация — спрошу. Для версии на интервью предложу: анонимное создание, редирект, опциональный TTL, без полной аналитики в первой версии, если не попросите.

Масштаб: чтение сильно больше записи. Если цифр нет, проверю порядок: миллионы редиректов в день против тысяч созданий — тогда кэш горячих кодов и простая база на запись. Если запись тоже огромная — отдельно ключи и шарды.

API: POST /links {url, ttl?} → {code}; GET /{code} → 302. Идемпотентность создания не критична, коллизии кода — да: генерируем, пишем уникальный индекс, при конфликте ещё попытка.

Данные: ключ code, поля url, expires_at, created_at. Хранилище ключ-значение или таблица с PK по code. Кэш редиректа с TTL короче, чем у ссылки. Узкое место — генерация короткого кода и горячие ключи. Не тащу очередь в создание ссылки, пока не доказали, что синхронной записи не хватает. Не рисую микросервис аналитики, если клики не требовали.

Дальше интервьюер почти наверняка спросит: как генерировать код, как не столкнуться, что если кэш отстал от удаления ссылки. Отвечайте компромиссом: «кэш может отдать старое до TTL — для редиректа часто приемлемо; если ссылку отозвали по безопасности, инвалидируем явно и режем TTL». Это и есть раунд.

Проход 2. Уведомления — очередь и идемпотентность

Постановка: «нужно слать email/push по событиям заказа». Ближе к реальной backend-работе, чем лента соцсети.

Требования: какие каналы, гарантия доставки «хотя бы раз» или «ровно раз», можно ли опоздать на минуты, нужна ли локализация, кто ретраит, что видит поддержка. Без этого я нарисую не ту систему.

Масштаб: пик после распродажи важнее среднего RPS. Если HTTP от заказа должен ответить быстро — запись события и ответ, отправка асинхронно.

API: внутренний emit(event_id, type, payload) идемпотентный по event_id. Публичный пользовательский API здесь может не быть. Данные: журнал событий, таблица доставок (event_id, channel, status), чтобы повтор консьюмера не слал второе письмо.

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

Связь с обычным техэкраном прямая: тот же двойной POST и ключ, что в вопросах backend. Design-раунд проверяет, видите ли вы это на схеме, а не только в одном хендлере.

Частые ошибки, которые топят даже знающих людей

  • Сразу рисовать. Нет требований — нет системы, есть демонстрация памяти.
  • Молчать у доски. Интервьюер не может помочь.
  • Усложнять при малых цифрах. Kafka «для резюме» — минус.
  • Игнорировать отказ: нет таймаута, нет идемпотентности, нет «что скажет поддержка».
  • Путать кэш с источником правды. Скажите, что будет, когда кэш соврёт.
  • Не уметь сузить: «давайте пока без поиска и без мультирегиона». Это зрелость.

Не спорьте с интервьюером из статьи, которую вы учили ночью. Если он просит Postgres вместо Dynamo — работайте в его ограничениях и назовите цену. Раунд про сотрудничество, не про победу в архитектуре.

Отдельно: не подменяйте design live coding. Если просят набросать сигнатуру API — два-четыре метода, не код хендлера на три экрана. Если просят оценить ключ шарда — одна фраза «user_id, потому что все запросы пользователя должны попадать на один узел» плюс минус этого выбора (горячий пользователь). Глубже в код вас уведут на другом этапе; здесь важнее, что вы понимаете, зачем коробка стоит на схеме.

Как готовиться с нуля за три-четыре недели

  1. Неделя 1. Каркас наизусть как порядок шагов, не как текст. Блоки: кэш, очередь, реплика, шард — по одной странице своими словами.
  2. Неделя 2. Три задачи вслух по 45 минут: shorten URL, уведомления, rate limiter или загрузка файла. Диктофон. Без чужой схемы до своего прохода.
  3. Неделя 3. Ещё три: лента, поиск по каталогу, мессенджер в урезанном виде (доставка сообщений, без «как WhatsApp целиком»). Одна глубокая тема на задачу.
  4. Неделя 4. Два mock с человеком у доски или в Miro. Перебивание обязательно. Затем разбор своего прод-сервиса тем же каркасом — это часто важнее классики.

Живые прогоны удобно стыковать с подготовкой к интервью. Behavioral на финале не отменяйте: design без умения рассказать инцидент выглядит странно. Банк историй — в STAR с примерами.

Что рисовать и чем говорить

Прямоугольники и стрелки. Подписи: кто синхронно, кто через очередь. Рядом порядок цифр, не роман. Если доска физическая — крупно, не мелкий текст. Если английский — короткие фразы: «reads dominate, so cache the redirect; writes are rare, so one primary is enough until X». Шаблоны фраз — в разговорных шаблонах.

Вилку и design в одной реплике не смешивайте. Деньги — отдельный блок: ожидания по зарплате.

Частые вопросы

Нужно ли знать конкретные продукты AWS назубок?

Нет. Нужно сказать «очередь», «объектное хранилище», «управляемая реляционка» и зачем. Имя сервиса — бонус, если вы им пользовались. Враньё про прод, которого не было, вскроется на follow-up.

Что, если не знаю «правильной» цифры RPS?

Назовите порядок и спросите, ок ли такая гипотеза. Интервьюер подставит свои. Молчаливое гадание хуже явной гипотезы.

Junior: стоит ли готовить design, если в вакансии его нет?

Короткий каркас своего учебного сервиса — да. Полный трек классики — если цель middle в ближайший год. Не вместо SQL и проекта. Входные роли — junior-вакансии.

Можно ли пользоваться шпаргалкой с каркасом?

Порядок семи шагов в голове — да. Простыня чужой архитектуры Twitter на втором мониторе — нет, глаза и паузы выдадут, а follow-up убьёт.

Чем это отличается от «расскажите про ваш сервис»?

Тем же каркасом, но объект свой, цифры свои, инцидент свой. Часто это сильнее учебной задачи. Готовьте оба.

Что делать, если застрял на выборе базы?

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

Что сделать сейчас

Сегодня пройдите каркас на сокращателе ссылок вслух, 40 минут, без открытого блога. Запишите. Завтра — уведомления с очередью и ключом event_id. На выходных разберите своим каркасом один реальный сервис из резюме: требования, масштаб, где врёт кэш, где дубль.

Если в ближайшей вакансии design указан явно — добавьте один mock с перебиванием на этой неделе. Смотреть, нужен ли он на слоте, удобно по описаниям в backend-каталоге, а не по чужому списку «всем senior обязательно Kafka».