The Dependency Graph Discipline

Most teams cannot draw their service dependency graph. The discipline that keeps it accurate, queryable, and useful for incident response.

Source of truth

Three sources converge into a useful dependency graph. Code-derived shows intent; runtime-derived shows reality; the combined view catches the discrepancies that are usually the most interesting bugs.

Code-derived. Parse for outbound calls; most accurate to intent; lags refactors and dynamic-dispatch dependencies.
Runtime-derived. Instrumented outbound calls per cluster; the real-traffic shape including the surprises.
Combined. Intent-vs-reality cross-check; discrepancies surface forgotten dependencies and dead code.
Named owner. Per-graph responsible team in the org; without an owner, the graph rots within two quarters.

What the graph is for

Three primary uses justify the maintenance investment. Without named consumers, the graph becomes the documentation that nobody reads.

Incident response. "Service X is down; what else is affected?" answered in seconds, not by walking the team chat.
Migration planning. "Who depends on Y?" lookup; drives sequencing of refactors and deprecations.
On-call routing. Per-alert affected-node-to-team routing; pages the right team without manual lookup.
Named consumer per use. Each use has a responsible team; catches "graph exists but nobody uses it" as the real failure mode.

Maintenance

Maintenance keeps the graph honest. Auto-refresh, edge alerting, quarterly retirement review; without active maintenance, the graph becomes wallpaper within a quarter.

Auto-refresh from runtime. Per-cluster live update; the graph stays current as code and traffic shapes change.
Alert on unexpected new edges. Per-edge the "never-declared-dependency" flag; worth investigating; sometimes a real bug.
Quarterly retirement review. Per-quarter scan for "no one depends on it" services; retirement candidates surface.
Freshness banner. "Last updated X" header on every graph view; supports trust in the artefact.