diagram.mmd — sequence
Microservice Request Chain sequence diagram

A microservice request chain is the sequence of synchronous service-to-service calls triggered by a single client request in a distributed system — where each service may itself call one or more downstream services to fulfill its part of the work.

What the diagram shows

This sequence diagram traces a user-facing request as it propagates through four services: Client, Order Service, Inventory Service, and Payment Service.

The client sends a POST /orders request to the Order Service. To fulfill the order, the Order Service must first reserve stock by calling the Inventory Service. If inventory is insufficient, a 409 Conflict propagates back to the client without ever reaching the payment step. When stock is available, the Order Service calls the Payment Service to authorize the charge. A payment failure triggers a compensating call back to the Inventory Service to release the reservation — a simplified form of the Saga pattern. Only after both downstream calls succeed does the Order Service commit the order and return 201 Created.

Trace IDs are propagated at each hop, enabling distributed tracing tools to reconstruct the full call chain.

Why this matters

Synchronous request chains introduce latency compounding: the end-to-end response time is the sum of all hop latencies. They also create tight coupling — if the Payment Service is down, orders fail even if inventory is healthy. Understanding the call chain visually makes these trade-offs concrete and highlights where Circuit Breaker Pattern or async patterns (see Worker Queue Processing) should be introduced.

For how the gateway dispatches to the first service, see API Gateway Request Flow. To monitor this chain end-to-end, explore Distributed Tracing Flow.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

A microservice request chain is the sequence of synchronous service-to-service calls triggered by a single client request in a distributed system, where each service may call one or more downstream services to fulfill its portion of the work. A single user-facing action (such as placing an order) may traverse three or more services before a response is returned.
The client sends a request to the first service (e.g., Order Service). That service calls a downstream dependency (Inventory Service) to check stock. If stock is available, it calls another dependency (Payment Service) to authorize the charge. Failures at any hop propagate back up the chain. If Payment fails after Inventory was already reserved, a compensating call releases the reservation — a simplified form of the Saga pattern.
Use synchronous chaining when the result of each step is required before the next step can proceed — for example, you must confirm inventory before charging a customer. For operations where steps are independent or where immediate consistency is not required, prefer async event-driven patterns using queues, which decouple services and improve resilience.
Latency compounds with every hop — the total response time is the sum of all service latencies, not just the slowest. Tight coupling means that if the Payment Service is down, the entire order flow fails even if inventory is healthy. Teams frequently underestimate these effects until they have three or more services in the chain. Adding circuit breakers at each hop and considering async patterns for non-critical steps are the standard mitigations.
mermaid
sequenceDiagram participant C as Client participant OS as Order Service participant IS as Inventory Service participant PS as Payment Service C->>OS: POST /orders (trace-id: abc123) OS->>IS: Reserve stock (trace-id: abc123) alt Insufficient stock IS-->>OS: 409 Insufficient inventory OS-->>C: 409 Order cannot be fulfilled else Stock reserved IS-->>OS: 200 Reserved (reservation-id: r99) OS->>PS: Authorize payment (trace-id: abc123) alt Payment declined PS-->>OS: 402 Payment failed OS->>IS: Release reservation r99 IS-->>OS: 200 Released OS-->>C: 402 Payment declined else Payment authorized PS-->>OS: 200 Authorized (charge-id: ch77) OS->>OS: Commit order to database OS-->>C: 201 Created (order-id: o55) end end
Copied to clipboard