Dependency Graphs: Seeing the Blast Radius Before the Incident
Dependency graphs turn scattered imports, service calls, and package manifests into a map of what depends on what, so impact and risk become visible.
Definition
A dependency graph is a directed representation of relationships between components, such as services, packages, or data sets, where an edge means one component requires another to function or to build.
Context and scope
Graphs are used for impact analysis before a change, incident triage during an outage, and supply chain review after a vulnerability disclosure.
Common misconceptions
- Graphs are only for security scanning — the same edges answer change impact and latency questions
- Build and runtime graphs are interchangeable — they describe different failure modes
- A complete graph is required — partial graphs with a stated boundary still answer most questions
Anti-patterns
- Building a graph from stale manifests and presenting it as current
- Treating every edge as critical, so the graph is all red and useless
- Drawing graphs nobody can query during an incident
Related concepts
Authoritative source
What the edges mean
A dependency graph is only as useful as its edge semantics. An edge can mean “compiles against”, “calls at runtime”, “reads data from”, or “deploys alongside”, and each answers a different question. Mixing them into one undirected picture produces a diagram that looks impressive and explains nothing. Name the edge type before drawing the line.
Build, runtime, and data graphs
The build graph comes from package manifests and import statements. The runtime graph comes from traces, service mesh telemetry, or network flow logs. The data graph comes from lineage metadata. They overlap but are not the same: a library can be a build dependency without being called at runtime, and a service can call another without declaring it anywhere. Use the graph that matches your question.
Impact analysis
Before a change, walk the graph forward: which services depend on the component being modified, and what is their criticality? During an incident, walk it backward: what does the failing component depend on? For example, a schema change to an events table is low risk until the graph shows four downstream consumers, two of which have no owner.
Keeping the graph honest
Graphs decay faster than diagrams because they claim precision. Rebuild them on every deploy, mark inferred edges as inferred, and record when each edge was last observed. Delete edges that have not appeared in telemetry for a defined window, but keep them in an archive so you can explain historical decisions.
Compared to an architecture diagram
A diagram communicates intent to humans; a graph supports queries by machines. The diagram says “orders talks to payments”; the graph answers “which of the 300 services would notice if payments were unavailable for ten minutes”. Mature teams keep both, generated from the same source of truth.