Кейс: распил монолита службы доставки еды
Вопрос
Монолит сервиса доставки еды тормозит релизы: 8 команд, выкатка раз в две недели. Руководство хочет микросервисы. С чего начнёшь как аналитик и как предложишь первые шаги?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Понять цель: что именно болит (релизы, нагрузка, надёжность), метрики успеха
Карта домена и ограниченных контекстов: каталог ресторанов, заказы, оплата, курьеры, уведомления
Выбор первого кандидата: слабосвязанный, часто меняемый, понятный (уведомления, каталог)
Strangler fig: постепенный вынос за фасадом, данные и события
Контракты, консистентность, наблюдаемость до выноса
Риски и критерии остановки
Что могут спросить следом
- Почему не начать с заказов, раз они самые важные?
- Как переносить данные из общей базы?
Разбор
Начну с цели: что болит, медленные релизы, нагрузка в пики или надёжность, и как измерим успех, например частоту релизов и долю инцидентов. Потом карта домена: каталог ресторанов, корзина и заказы, оплата, курьеры и логистика, уведомления, лояльность. Смотрю связи и частоту изменений по командам. Первым выношу слабосвязанный и часто меняемый контекст, например уведомления или каталог, а не ядро заказов: на нём команда научится, не рискуя деньгами. Делаю по схеме strangler fig: фасад направляет часть вызовов в новый сервис, данные синхронизируются событиями, затем старый код удаляется. До выноса описываю контракты, консистентность и мониторинг. Фиксирую риски и критерии, при которых останавливаемся.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.