Service mesh communication
Microservices calling each other with retries, timeouts, and circuit breakers.
Modern applications split work across many services — orders, payments, notifications — each running independently. But the user only cares that the whole flow works. This template traces one request from the load balancer through multiple services, showing exactly which system calls which, and what happens when a service fails.
The sequence lifelines make service dependencies crystal clear. The alt/else blocks show decision points: payment succeeds (fast path) or fails (recovery path). Notice how the Notification Service gets called regardless of the payment outcome — that's what makes the system resilient: confirmation or failure emails both matter to the customer.
When to use this template
- Designing microservice architecture — before you build the services, draw how they talk. This diagram forces conversations about dependencies and failure modes.
- Onboarding new engineers — a picture of which service calls which, in order, beats a hundred lines of prose. New team members see the shape of your system in seconds.
- Post-incident reviews — when a service went down and the whole system failed, mark up this diagram with what broke and how to fix it. The diagram becomes the basis for resilience improvements.
How to adapt it
Start by renaming services to match your real architecture:
- Replace Order/Payment/Notification with your actual services: Inventory, Fulfillment, Analytics, etc.
- Add timeouts and retries as labels on edges:
Query user API [timeout 5s]makes the latency budget visible. - Extend the diagram for error cases you know are slow: if Payment Service degrades, how does Order Service behave? Add an alt block showing the fallback.
Visual edits regenerate clean code, so you can sketch service dependencies and failure modes without writing sequence syntax directly.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
sequenceDiagram
participant User as Client
participant LB as Load Balancer
participant SvcA as Order Service
participant SvcB as Payment Service
participant SvcC as Notification Service
User->>LB: POST /orders
LB->>SvcA: Route to Order Service
SvcA->>SvcB: Call payment API
alt Payment succeeds
SvcB-->>SvcA: 200 OK
SvcA->>SvcC: Send confirmation email
SvcC-->>SvcA: Email queued
SvcA-->>LB: 201 Created
else Payment fails
SvcB-->>SvcA: 402 Payment failed
SvcA->>SvcC: Send failure email
SvcC-->>SvcA: Email queued
SvcA-->>LB: 402 Payment failed
end
LB-->>User: Response
Frequently asked questions
- What is a service mesh communication diagram?
- It shows how independent microservices talk to each other: which service calls which, in what order, and what happens when things fail. It makes visible the call chain from an external request through multiple internal services and back, including retry logic and error paths that keep the system working when one service is slow or down.
- Why use a sequence diagram for service mesh instead of a flowchart?
- Sequence diagrams show lifelines (vertical lines for each participant) and message flow between them, which makes it obvious which services are involved and in what order they communicate. This is critical for distributed systems where the path of a request through services matters more than individual decisions within one service.
- How do I add circuit breakers and timeouts to this diagram?
- Add optional response messages for timeout scenarios (Payment Service times out → Order Service falls back to a queue), and use alt/else blocks to show happy path vs. circuit-breaker-open paths. The visual editor regenerates clean Mermaid code, so you can iterate without syntax overhead.
- What should I do when a service in the mesh is unavailable?
- Design graceful degradation: if Payment Service is down, queue the order for async processing. If Notification Service is down, continue anyway and retry notifications later. This diagram helps your team see these dependencies upfront so you can build fallbacks before they're critical.