Как я работаю с System Design на менторинге

Недавно разбирали с кандидатом задачу - реализовать трекинг машины. Казалось бы, просто "покажи точку на карте". Но именно такие задачи хорошо показывают, умеет ли человек думать как инженер, а не как кодер.

Вот структура, которую я использую и которую рекомендую отработать до автоматизма:

1. Функциональные требования - сначала скоуп, потом всe остальное.
   Что входит, что явно out of scope, кто пользователь, какой happy path. Без этого любой дизайн стрельба вслепую.
2. Нефункциональные требования - думай глобально.
   Latency, availability, consistency, допустимый staleness данных. В нашей задаче ключевым оказался SLA 100ms и именно это может сильно определять архитектуру.
3. Capacity Estimation - цифры диктуют решениею
   Быстрая черновая прикидка за 2-3 минуты прямо на интервью. Не нужна точность - нужен порядок величин.
   В нашем кейсе: 10 000 активных заказов, polling раз в минуту -> 170 RPS, все состояние в кеше -> 500 KB. Три строчки - и сразу ясно что Redis на одной ноде справится, а Kafka и Cassandra здесь просто не нужны.
   Главное что дает estimation - ты видишь где реальная проблема. В нашем кейсе это не масштаб, а latency. Значит туда и идем, не отвлекаясь на лишнее.
4. API Contract - снаружи внутрь
   Прежде чем рисовать "квадратики и стрелочки" - зафиксируй интерфейс. Это дисциплинирует мышление и сразу показывает интервьюеру, что ты думаешь о потребителе.
5. Data Model - отдельно, не внутри "дизайна"
   SQL vs NoSQL под конкретные access patterns, что и как кешируем, какие TTL.
6. High-Level Design по C4
   System Context -> Containers. Не надо сразу рисовать 15 микросервисов. Сначала покажи систему в окружении, потом основные блоки с обоснованием технологий.
7. Deep Dive в критический компонент
   Интервьюер всегда попросит углубиться. Будь готов объяснить failure modes, retry logic, idempotency. В нашей задаче это был Sync Worker, который фоново тянет координаты и пишет в кеш.
8. Trade-offs. Это про зрелость решений.
   Не "я выбрал Redis потому что знаю Redis". А "я выбрал cache + background sync, потому что клиент обновляет координаты раз в 30 секунд - staleness допустим, а 350ms sequential chain нарушает SLA. Альтернатива X не подошла потому что Y."

Что я часто вижу у кандидатов:

• Прыгают к решению не уточнив скоуп
• Пропускают capacity estimation и архитектура висит в воздухе
• Молчат. Интервью по system design это диалог, а не лекция
• Не проговаривают от чего отказались и почему

Хороший system design это не знание паттернов наизусть. Это структурированное мышление, умение работать с ограничениями и объяснять компромиссы. А еще нужно уместиться в среднем в 1 час интервью.
Именно это и тренируем.