Case Study: An E-Commerce Order Flow

One design, many patterns

Consider a shop. The Orders service accepts PlaceOrder synchronously (the user needs an answer), validates it, saves the order and an OrderPlaced row in its outbox in one transaction, and replies "Order received". A relay publishes the event to a log-based broker keyed by order ID. An orchestrated saga (a workflow engine) reserves stock with Inventory, then charges the card with Payments using an idempotency key; on failure it releases stock and publishes OrderCancelled. Each step emits events: StockReserved, PaymentCaptured, OrderConfirmed. Notifications consumes them to email the customer; Search and Analytics consume them independently. A projection builds the customer's "My orders" read model, and the UI shows "Processing…" until OrderConfirmed arrives. Every event carries a correlation ID and trace context, consumer lag and DLQs are monitored, and the event catalogue documents owners and schemas.

The order flow end to end

A synchronous command at the edge, then events, a saga and projections behind it.

The sequence of events for a successful order

Each line is a separate event on the bus, linked by one correlation ID.

correlation chk-77a1

1  OrderPlaced        orders      -> saga, analytics, search, projection
2  StockReserved      inventory   -> saga
3  PaymentCaptured    payments    -> saga, accounting
4  OrderConfirmed     orders      -> notifications, projection, analytics
5  ShipmentScheduled  shipping    -> notifications, projection

failure branch after 2:
3' PaymentFailed      payments    -> saga
4' StockReleased      inventory   (compensation)
5' OrderCancelled     orders      -> notifications, projection

Draw the flow before writing code

Event storming, a workshop technique where domain experts and developers place sticky notes for events, commands and policies on a wall, surfaces the business flow and its failure paths before you choose topics and services.

त्वरित जाँच: In this design, why is PlaceOrder handled synchronously?

• Brokers cannot handle commands
• To avoid using an outbox
• The user needs immediate validation and an acknowledgement, while later steps can run asynchronously
• Because sagas require it