title Microservices Order Flow type database "Orders DB" API Gateway -> Order Service: POST /orders Order Service -> Inventory Service: check stock Inventory Service -> Order Service: stock available Order Service -> "Orders DB": save order Order Service -> Message Queue: publish order.created Message Queue -> Inventory Service: reserve inventory Message Queue -> Notification Service: send confirmation email Order Service -> API Gateway: 201 Created
What this diagram shows
The useful line in this diagram is where the queue starts. Everything left of it is synchronous, and the customer is waiting on it. Everything right of it happens whenever it happens. That's also where the classic bug lives: the confirmation email that arrives before the order finishes saving.
Honestly, the queue is the part people get wrong most often. It's why a slow email provider can't slow down checkout, and it deserves its own box rather than a label on an arrow.
Step-by-step flow breakdown
POST /orders to the Order Service.order.created event and does not wait for consumers.201 Created back, no matter how long the queue consumers take.When to use this flow diagram
- System design interviews. This is the sketch, ready in a minute.
- Showing where sync ends and async begins, which is usually the question that matters.
- Incident review. Was the bug in the request path or in a queue consumer?
- Proposing a design before anyone writes it.
Common variations
Add a payment step
Put Order Service -> Payment Service: charge card before the database write. The payment example has that whole round trip.
Saga / compensation
Add the failure path: Inventory Service -> Message Queue: out of stock, then a cancel arrow back to Order Service.
Multiple queue consumers
Queues are cheap to fan out. Add Message Queue -> Analytics Service: track order and whatever else wants to listen.
Related flow diagram examples
Frequently asked questions
What does this diagram show?
One order request spreading across services: the synchronous calls first, then the queue handing work to whoever subscribed.
How do I diagram my own microservices flow?
Chain the sync calls first, then draw the queue as its own box with an arrow to each consumer. Keeping the queue visible is the whole point.
Does this replace a proper architecture diagram?
For explaining a flow to a person, yes. For VPCs and load balancers you still want an infra diagram. This is the logical picture.