An order is a workflow
Placing an order is not one action. It reserves inventory, charges payment, allocates a warehouse, and schedules shipping. These steps span services and must coordinate without a single giant transaction.
Event driven stages
Each stage emits an event when done, and the next stage listens for it. This decouples services so a slow shipping system does not block payment, and stages can scale independently.
- Order placed emits an event
- Inventory, payment, and fulfillment each react in turn
- Services communicate through events, not direct calls
The saga pattern
Without one transaction across services, partial failure is the risk. The saga pattern handles this: if a later step fails, earlier steps run compensating actions, like releasing reserved inventory or refunding a charge.
The pipeline stays reliable by decoupling stages with events and undoing partial progress with compensating actions.
Key idea
Model an order as event driven stages and use the saga pattern with compensating actions so the workflow stays consistent even when a step fails midway.