Service Dependency Maps & Impact Analysis

A service dependency map answers a conditional question: if this component or path is impaired now, which service outcomes could be affected? It is not one static architecture drawing. Production dependencies vary by version, tenant, region, feature flag, cache state, route, retry, and time. The useful artifact is therefore a typed, versioned graph assembled from several evidence sources.

The map narrows diagnosis and estimates blast radius. It does not establish root cause. A failed dependency can be unused for the affected request; a saturated component can be a consequence of retries elsewhere; two red nodes can share an upstream cause that is missing from the graph.

Model typed facts, not generic lines #

Represent each node with a stable identity and type. Useful types include:

• user journey or service;
• API or operation;
• logical service component and service instance;
• queue, topic, cache, database, or external provider;
• deployment, process, container, virtual machine, host, and storage volume;
• subnet, load balancer, firewall, router, interface, link, tunnel, and provider circuit;
• failure domain such as rack power, availability zone, controller, certificate authority, or identity service.

Edges need verbs and direction:

• calls, publishes_to, reads_from, writes_to;
• hosted_on, scheduled_on, attached_to;
• routes_over, encapsulated_by, protected_by;
• configured_by, authenticated_by, resolved_by;
• supported_by for an overlay or logical topology mapped onto an underlay.

A generic “depends on” edge loses whether the dependency is on the request path, control path, deployment path, or recovery path. DNS or identity may not be touched on every steady-state request but can still block new connections or failover.

Each edge should also carry scope and evidence: first and last observation time, environment, region, version, operation, source, and confidence. This turns disagreement into inspectable data rather than an argument over which diagram is official.

A graph is not necessarily a tree or DAG #

Layered diagrams often draw service → application → compute → network as a tree. That is a useful projection, not a structural guarantee.

• Several services share one database, queue, DNS resolver, certificate authority, or network path.
• One service fans out to several dependencies and may require all, any one, or a quorum.
• Retries, callbacks, event consumers, and control APIs create cycles in the service-level graph.
• A request trace is usually represented as a causally ordered span structure, while the aggregate graph built from many traces can contain cycles.
• Redundant logical links may share one supporting physical link, power feed, or controller.

Do not force the graph into a tree merely to simplify traversal. Instead, label edge semantics and define the analysis projection: request path, deployment path, control path, or failure-support graph.

Evidence sources #

Declared inventory and configuration #

Infrastructure definitions, service catalogues, deployment manifests, routing intent, and ownership registries describe what should exist. They cover cold paths and recovery dependencies that traces may not exercise. Their weakness is staleness: declared intent can differ from applied and operational state.

RFC 8345 provides a generic YANG topology vocabulary of networks, nodes, links, and termination points. It also models supporting networks, nodes, and links, which is essential for relating an overlay to its underlay. A configured topology and a system-controlled discovered topology are distinct views.

Runtime discovery and telemetry #

Orchestrators, cloud APIs, routing protocols, neighbour tables, and device operational state reveal what exists now. They are good for instance and path membership but can churn rapidly. Preserve event time and identity generation so a recycled address does not attach old evidence to a new object.

Distributed traces #

Traces reveal calls that actually occurred for sampled requests. OpenTelemetry identifies a logical service with resource attributes such as service.namespace and service.name, distinct from service.instance.id. Consistent identity is what allows spans from many processes to form one service node.

The OpenTelemetry Collector service graph connector pairs client/server, producer/consumer, and certain database spans to emit edge metrics. Its limitation is instructive: it needs both sides of an edge, and sampled or differently routed spans can prevent pairing. An inferred graph is an observation of captured traffic, not a complete service catalogue.

Active probes and packet or flow evidence #

Probes test chosen paths and operations even when user traffic is absent. Packet and flow evidence can confirm that traffic used a network path, but encryption, asymmetric routing, tunnelling, NAT, sampling, and observation placement limit interpretation. Use these sources to verify or annotate an edge, not to guess application semantics from addresses alone.

Merge without erasing provenance #

Store source assertions separately before resolving them into a view:

When sources disagree, preserve the disagreement and ask which state each one represents. A manifest may be desired state, an orchestrator record applied placement, and a trace observed behavior. Collapsing them into one unlabeled edge destroys the most valuable diagnostic distinction.

Impact analysis #

Given an impaired node or edge, upstream traversal through dependency edges finds services that could be affected. The result is a candidate blast radius, which should be narrowed by:

• time overlap between impairment and service traffic;
• operation, tenant, region, version, and feature scope;
• edge requirement: hard, optional, fallback, quorum, or cached;
• whether the affected path was selected;
• whether retries or redundancy succeeded;
• user-facing SLI evidence.

If a shared database is impaired, every service with a reads_from edge is not automatically down. One may use a warm cache, another may use a different shard, and a third may touch the database only on writes. Edge conditions are part of impact semantics.

Root-cause candidate ranking #

Given several affected services, downstream traversal finds common dependencies. Rank candidates using independent evidence:

1. the candidate lies on observed paths for the affected operations;
2. its abnormal signal precedes or begins with user impact within clock uncertainty;
3. unaffected services that share it are explained by path, load, or redundancy differences;
4. the candidate's failure mode predicts the observed symptom and direction;
5. recovery or a controlled change produces the predicted response.

This is hypothesis ranking, not proof by topology. A retry storm can saturate a shared database after an upstream timeout begins; the database is then common and red but secondary.

Worked incident: checkout latency #

Symptoms: the checkout latency SLI burns budget in one region, while application CPU and database latency are normal.

1. Select traces for bad checkout events and compare them with good events from the same region and version.
2. The graph shows both cohorts call payments, but bad traces use one payments instance behind a regional load balancer.
3. Instance placement maps that target to one host and one overlay path. RFC 8345-style supporting links map the overlay to an underlay port channel.
4. Forwarding telemetry shows egress queue drops on one member link during the same interval; interface-average utilization is modest.
5. Packet evidence on the path shows retransmission and rising round-trip time in the affected direction.
6. Other services using the same port channel are checked. Their traffic class and packet size differ, explaining why their SLIs remain healthy.

The graph made the network path a testable candidate. Queue and packet evidence supplied the mechanism. The service SLI established the impact. None of the three alone would be enough.

Freshness and graph health #

Measure the map itself:

• percentage of services with an owner and objective;
• proportion of trace edges with both sides instrumented;
• age distribution of declared and observed edges;
• unresolved identities and address reuse;
• edges present in runtime but absent from declared inventory, and vice versa;
• topology updates lost or delayed;
• services whose path cannot be mapped through the network layers;
• cardinality growth from unstable service or instance names.

Keep historical versions long enough to reconstruct an incident. Replacing yesterday's topology with today's removes evidence about the path that actually failed.

Design checklist #

• Define the analysis projection: request, control, deployment, recovery, or failure support.
• Use stable typed node identities; separate service from instance.
• Give every edge a verb, direction, scope, source, confidence, and time interval.
• Preserve desired, applied, discovered, and observed assertions separately.
• Model shared dependencies, alternatives, quorum, caches, and cycles.
• Map logical network edges to supporting underlay and failure domains.
• Treat trace-derived edges as sampled observations, not complete inventory.
• Use topology to select hypotheses; require telemetry and timing evidence for causal claims.
• Validate blast radius against user-facing SLIs before escalating every upstream service.
• Version the graph so an incident can be replayed against the topology that existed then.