Service dependency graph
Map which services depend on which, and visualize failure cascades.
Every system eventually reaches a point where a single service's failure cascades silently through the rest of the infrastructure. This template maps those dependencies: who calls whom, and in what pattern. The diagram answers the question every on-call engineer asks during an incident: "If this service is down, what else breaks?"
Knowing your dependency graph is the difference between a localized outage and a company-wide incident. It forces you to see bottlenecks (services that many others depend on) and to ask: do we have redundancy? Do we have timeouts? Do we have a circuit breaker there?
When to use this template
- Incident postmortems — trace the failure cascade: which service failed first, which others depended on it, and could you have isolated the blast radius?
- Architecture reviews — new teams joining the company need to see which services are safe to call, which are fragile, and which are load-shedding under stress.
- Resilience planning — identify single points of failure (services with many dependents) and prioritize adding redundancy, circuit breakers, or caching.
How to adapt it
Start with your actual service names and relationships. Then add:
- Asynchronous calls — distinguish between sync calls (failures block) and async calls (failures queue/retry). Use different arrow styles or labels to show intent.
- External dependencies — add third-party APIs (payment gateways, map services) and show which internal services depend on them.
- Failover paths — annotate edges with fallback behavior: "calls Cache, falls back to Database", or "calls Primary, retries Secondary on failure".
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
erDiagram
"API Gateway" ||--o{ "Auth Service" : calls
"API Gateway" ||--o{ "User Service" : calls
"API Gateway" ||--o{ "Order Service" : calls
"Order Service" ||--o{ "Inventory Service" : calls
"Order Service" ||--o{ "Payment Service" : calls
"Payment Service" ||--o{ "Fraud Detection" : calls
"User Service" ||--o{ "Cache Layer" : reads
"Inventory Service" ||--o{ "Cache Layer" : reads
"Auth Service" ||--o{ "Database" : reads
"User Service" ||--o{ "Database" : reads
"Order Service" ||--o{ "Database" : reads
Frequently asked questions
- What is a service dependency diagram?
- It maps which services call which other services in your system. It answers: if Auth Service goes down, what else breaks? If the cache layer is slow, which user flows degrade? Dependency graphs force teams to see the blast radius of each service and identify critical path bottlenecks before they cause outages.
- How do I identify all the dependencies in my system?
- Start by listing every service in your architecture (API Gateway, databases, caches, business services). Then for each service, ask: which other services does it call synchronously (failures block it)? Which does it call asynchronously (failures degrade gracefully)? Use log traces, distributed tracing output (Jaeger, DataDog), and code review to build the picture.
- Why use an ER diagram for dependencies instead of a flowchart?
- ER diagrams show relationships and cardinality (one-to-many), which map perfectly to service dependencies. Flowcharts are for processes and decisions. ER lets you see at a glance which services fan out to many others and which are leaf nodes — that topology is the key to understanding your system's failure surface.
- How do I use this to improve reliability?
- Look for single points of failure — services that many others depend on, like your Database or Cache Layer in this template. Those are your priority for redundancy, monitoring, and automated recovery. Services with no dependents (leaf nodes) can fail less catastrophically. Use this diagram to guide circuit breaker placement and timeout tuning.
Related templates
Circuit breaker pattern
Fail fast and recover gracefully when downstream services fail.
Saga pattern: distributed transaction
Choreography-based saga with compensating transactions on failure.
API gateway request routing
Gateway routing requests to microservices based on path and headers.