title Microservices Order Flow participant "API Gateway" as GW participant "Order Service" as Orders participant "Inventory Service" as Inv participant "Notification Service" as Notify participant "Message Queue" as MQ GW->Orders: POST /orders Orders->Inv: Check stock Inv-->Orders: Stock available Orders->Orders: Create order Orders->MQ: Publish order.created MQ->Inv: Reserve inventory MQ->Notify: Send confirmation email Inv-->MQ: Inventory reserved Orders-->GW: 201 Created + order ID
What this diagram shows
This sequence diagram illustrates an event-driven microservices architecture for order processing. It shows both synchronous communication (Order Service checking inventory before creating the order) and asynchronous event publishing (publishing order.created to a message queue for downstream consumers).
The pattern — synchronous validation + asynchronous side-effects via events — is the backbone of platforms like Amazon, Shopify, and most modern e-commerce backends. It keeps services loosely coupled: the Order Service doesn't know or care whether Inventory or Notification services are running.
Step-by-step flow breakdown
POST /orders through the gateway, which handles auth and routes to Order Service.pending.When to use a microservices sequence diagram
- Architecture design — agree on which calls are sync vs. async before writing any code
- Service boundary decisions — identify which services need to know about each other vs. which can be fully decoupled via events
- Failure mode analysis — trace what happens when the queue is unavailable or a consumer crashes
- Onboarding — give new engineers a map of the service graph for a specific use case
- Tech spec / RFC — include in design documents for cross-team review
Common variations
Saga pattern (distributed transaction)
Add compensating transactions: if inventory reservation fails, publish order.cancelled to roll back the order. Each service listens for failure events and undoes its work.
CQRS with event sourcing
Replace the direct database write with an event store. Order Service publishes OrderCreated to the event store, which becomes the source of truth and fans out to read-model projections.
Multiple consumers
Add Shipping Service, Analytics Service, or Fraud Detection as additional message queue consumers of order.created without changing Order Service at all.
gRPC instead of REST
Replace POST /orders with a gRPC call notation. The rest of the pattern is identical — the synchronous/asynchronous split remains the key design decision.
Related sequence diagram examples
Frequently asked questions
How do you diagram microservices communication?
Each microservice is a participant. Synchronous calls use solid arrows (->); async event publishing uses dashed arrows (-->). The message queue is its own participant that receives events from producers and delivers them to consumers.
What is an event-driven microservices diagram?
It shows how services communicate via a message queue or event bus rather than calling each other directly. One service publishes an event (order.created) and one or more consumers handle it asynchronously — decoupling producers from consumers.
Should the inventory check be synchronous or async?
The initial stock availability check (before creating the order) should be synchronous — you need the answer before committing. Inventory reservation (locking stock) can be async after the order is created, since it's a side-effect rather than a gate.
Can I edit this microservices diagram for my own services?
Yes — click Open in Editor. Replace the service names with your own, add or remove participants, and export as PNG, SVG, or Mermaid. Free, no account required.