Спроектируйте интеграцию интернет-магазина со службой доставки: передача заказов и получение статусов. Какие вопросы зададите и что опишете в постановке?
Короткий ответ
- Сначала вопросы: объёмы, SLA, какой API у службы
- Создание отправления — синхронный REST-вызов с идемпотентным ключом
- Статусы — вебхуки от службы плюс резервный опрос
- Маппинг статусов доставки на статусы заказа магазина
- Обработка ошибок: ретраи с backoff, алерты, ручной разбор
- Безопасность: авторизация, подпись вебхуков, HTTPS
- В постановке: sequence-диаграмма, контракт, маппинг, НФТ
Решение — синхронное создание отправления с идемпотентностью и получение статусов вебхуками с резервным опросом, а в постановке фиксируются контракт, маппинг статусов, обработка ошибок и мониторинг.
Как сказать вслух
пример ответаНачну с вопросов: какой API предоставляет служба доставки, какие объёмы заказов, насколько быстро бизнесу нужны статусы. Дальше спроектирую два потока. Создание отправления — синхронный вызов их API при передаче заказа в доставку, обязательно с идемпотентным ключом, чтобы ретрай не создал дубль. Статусы — лучше вебхуками от службы с проверкой подписи, плюс резервный опрос по расписанию на случай потерянных вебхуков. Отдельно опишу маппинг их статусов на наши, поведение при недоступности их API и мониторинг.
Подробный ответ
Основной ответ
Проектирование начинается с уточнения контекста: возможности API контрагента (REST, вебхуки, SOAP, выгрузки), объёмы и пики, требуемая бизнесом скорость обновления статусов, договорный SLA. Поток «создание отправления»: по событию готовности заказа магазин синхронно вызывает API службы, передаёт состав, адрес, габариты, получает трек-номер; запрос снабжается идемпотентным ключом (номер заказа), при недоступности — ретраи с экспоненциальной задержкой через очередь отложенных задач, после исчерпания — алерт и ручная обработка. Поток «статусы»: подписка на вебхуки с проверкой подписи и быстрым ответом 200 (обработка асинхронно), резервный опрос раз в N часов по незакрытым отправлениям — вебхуки теряются. В постановке: sequence-диаграммы обоих потоков, спецификация вызовов, таблица маппинга статусов (включая неизвестные статусы), сценарии ошибок, журналирование обменов, метрики и алерты, требования безопасности.
Ключевые моменты
- Вопросы до решения. API и ограничения контрагента, объёмы, допустимая задержка статусов, SLA — выбор архитектуры зависит от ответов.
- Идемпотентность создания. Ключ по номеру заказа защищает от дублей отправлений при таймаутах и повторных попытках.
- Вебхуки плюс опрос. Вебхуки дают скорость, резервный polling по незакрытым заказам страхует от потерь; обязательна проверка подписи.
- Маппинг и ошибки. Таблица соответствия статусов с поведением для неизвестных значений, ретраи, DLQ, алерты и журнал обменов для разборов.
Практический контекст
Это типовая задача системного аналитика в e-commerce и типовой интервью-кейс. Оценивают не «правильный ответ», а ход мысли: задаёт ли кандидат вопросы до проектирования, помнит ли про ошибки, дубли и потерянные вебхуки, или рисует только счастливый путь. Сильный сигнал — кандидат сам говорит про маппинг статусов и про то, что делать с заказом, когда служба доставки лежит.
Частые ошибки
- Проектируют только успешный сценарий без недоступности контрагента и дублей
- Полагаются только на вебхуки, забывая, что они теряются и требуют резервного опроса
- Не описывают маппинг статусов и поведение при неизвестном статусе