What is the difference between a service dependency graph and a relationship graph?

How the Two Graphs Serve Different Questions

A service dependency graph is designed for operational impact analysis. It models what depends on what, so teams can reason about blast radius, outage propagation, and incident prioritisation. A relationship graph is broader: it can include context like ownership, documentation links, change history, or correlation that helps humans understand the environment without implying runtime failure flow.

The practical difference is intent. Dependency graphs answer, “If this service fails, what else is affected?” Relationship graphs answer, “How is this service connected to other things we know about it?” That means the same node pair can be valid in both graphs, but the edge meaning is not interchangeable.

In practice, dependency edges must be directional and conservative. If you allow contextual links to behave like propagation paths, you will overstate impact and create false incident dependencies. That is why incident response, service restoration, and resilience planning should start from the narrower model, then consult the broader graph for surrounding context.

Why Edge Semantics Matter in Incident Response

The biggest error practitioners make is treating every relationship as if it were a failure path. Ownership, co-location, shared codebase, or observability correlation may be useful during triage, but they do not necessarily mean one service can break another. The narrower dependency view keeps response teams focused on actual upstream and downstream runtime dependencies.

This distinction also affects maintenance windows and change analysis. A relationship graph may reveal that two services are maintained by the same team or deployed from the same repository, but that does not mean a rollout in one service will directly disrupt the other. Dependency graphs are the safer source for propagation assumptions, because they are built around operational causality rather than general association.

For readers working with cloud-native systems, the same principle appears in supply-chain and inventory thinking. Open source dependency maps can show what components are transitive and operationally relevant, while broader catalog graphs can show where components came from, who owns them, or how they are documented. OpenSSF’s guidance on software supply chain security is useful here because it reinforces the need to distinguish provenance and governance metadata from runtime dependency behaviour.

When to Use Each Graph, and What to Avoid

Use a service dependency graph when you need to assess outage impact, sequence a recovery, or decide whether a change can safely proceed. Use a relationship graph when you need discovery, context, stewardship, or investigative enrichment. Both are valuable, but they solve different problems and should not be merged casually.

What to avoid is semantic drift. A relationship graph often grows faster because it is easier to add edges than to prove causal dependency, but that convenience can make the graph unreliable for operational decisions. The safest pattern is to label edge types explicitly and keep traversal rules tied to the use case, so responders can see at a glance which links are causal and which are contextual.

For governance and architecture teams, the most useful test is whether an edge would still matter if the related system stopped influencing runtime behaviour. If the answer is yes, it belongs in the relationship graph. If the answer is no, it belongs in the dependency graph or should not be used for impact analysis at all.

Practitioner Guidance

What to verify: Confirm that dependency edges are derived from observed runtime behaviour, not from ownership, CMDB relationships, or documentation links. If a graph mixes those meanings, incident responders will make bad propagation assumptions.

Decision rule: If the question is about outage, blast radius, or recovery order, use the dependency graph first. If the question is about stewardship, inventory, or investigation context, use the broader relationship graph, but keep it out of the failure path model.

Common mistake: Teams often build one graph and then ask it to serve both purposes. That usually works until the first serious incident, when contextual edges are mistaken for causal ones and the response sequence becomes too broad.

Practitioner takeaway: The right graph is the one whose edge semantics match the decision you are trying to make, because operational confidence depends more on meaning than on connectivity.

Related navigation: OpenSSF is a useful reference point for separating supply chain context from runtime dependency analysis.

Related resources from NHI Mgmt Group

• What is the difference between lockfile based dependency scanning and graph based dependency visibility?
• What is the difference between a service factory and a service factory builder in dependency injection?
• What is the difference between a static asset inventory and a relationship graph for security operations?
• What is the difference between a valid service provider contract and an unsupported third-party relationship under CPRA?