Topology
Status: ✅ Decided — grounded in ADR-0011
Topology is the connectivity graph of infrastructure: which spans connect where, which services depend on which spans, which customers are reachable through which paths. The kernel implements topology as Postgres adjacency tables with recursive CTEs for bounded traversals, plus a precomputed service-dependency projection for blast-radius queries.
Bounded traversals (trace path, k-hop continuity) use recursive CTEs against the adjacency tables. These handle normal graph queries well and do not require a separate graph store at proof scale.
Blast-radius — the set of services, sites, and customers affected by a failure at a given point — is the telecom killer feature and the query most likely to exceed latency targets at scale. Deep, unbounded graph traversal in CTEs degrades badly over millions of links. The decision: precompute a service-dependency projection (service → reachable spans), maintained by the Projection Engine, so blast-radius is a lookup against a materialized index, not a live deep traversal.
The entire topology engine sits behind a topology-engine interface so a dedicated graph store (Neo4j or similar) can be substituted later without rewriting callers. The dedicated graph store and 10M-link performance proof are deferred until a real dataset demands them.
Authority (link and traversal visibility policy) must apply to topology results, including the precomputed projection.
See also
- Concepts — Topology / Blast-radius
- Consistency — projection lag bounds blast-radius freshness
- ADR-0011 — topology decision
Open questions
- The precomputed service-dependency projection’s invalidation and update logic is a correctness requirement that the projection-rebuild tests must cover. The exact freshness SLA under ADR-0003’s async projection model is open until the consistency spike resolves.