# Case Study: An E-Commerce Order Flow — Event-Driven Architecture & CQRS

Source: https://www.skillbyai.com/en/event-driven-architecture/p-case

> Combine events, outbox, saga and CQRS in one realistic design.

## 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.

![A user box sending one arrow to a service, which feeds a broker bar; from the bar, arrows go to an orchestrator circle with three participant boxes and to several reader boxes.](assets/figures/event-driven-architecture/section-8-map.svg) — Figure 8.1 — Command, outbox, broker, saga and read models working together.

## The sequence of events for a successful order

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

```text
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.

**Quiz:** In this design, why is PlaceOrder handled synchronously?

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

*Answer:* The user needs immediate validation and an acknowledgement, while later steps can run asynchronously. Accept and validate at the edge synchronously, then let events drive the rest.