Order Processing Pipeline: кто владеет состоянием заказа

Частая ошибка в дизайне пайплайна обработки заказа — размазать состояние заказа по нескольким сервисам. Payment-сервис помечает заказ как оплаченный, warehouse — как зарезервированный, и каждый пишет напрямую в свою копию статуса.

Правильная модель: Order Service — единственный владелец состояния заказа. Остальные сервисы не трогают статус заказа напрямую, они публикуют события о своей части работы: order.created, payment.completed, warehouse.reserved, shipping.started. Order Service слушает эти события и сам переводит заказ из одного состояния в другое.

Ключевая деталь — outbox-таблица на каждом шаге. Payment-сервис в одной транзакции с изменением своих данных пишет запись в outbox, отдельный процесс читает outbox и публикует событие в очередь. Без этого есть окно, где данные в БД сервиса уже изменились, а событие ещё не ушло — и наоборот.

Это снимает классический вопрос «что если сервис упал между сохранением и публикацией события»: при outbox такого окна нет, потому что сохранение и запись в outbox — одна транзакция.

На собеседовании после этой схемы спрашивают: что если warehouse.reserved пришло раньше payment.completed — из-за задержки в очереди. Order Service должен уметь обрабатывать события не по порядку отправки, а переходить в состояние только когда выполнены все предусловия, а не по факту получения последнего события.

Outbox на каждом переходе — не опция для надёжности, а единственный способ избежать рассинхрона между БД сервиса и очередью событий.

Тренажёр: 900+ вопросов и задач, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки