サイロからサービストポロジーへ：NetflixがリアルタイムサービスマップをなぜつくったかFrom Silos to Service Topology: Why Netflix Built a Real-Time Service Map

Netflix has published an engineering account of how it built a unified, real-time service topology map to replace the fragmented, siloed views its teams previously relied on when reasoning about dependencies across thousands of microservices. The work matters because at Netflix's scale, no single engineer can hold the full shape of the system in their head, and during an incident the difference between a quick recovery and a prolonged outage often comes down to how fast responders can see how services connect and where failure is propagating.

The core problem the company describes is one familiar to most organizations running large distributed systems. Over years of growth, knowledge about service dependencies accumulated in scattered places: tracing systems, configuration management databases, deployment metadata, team wikis, and the institutional memory of individual engineers. Each of these sources captured a slice of the truth, but none offered a single, current picture. The result was what Netflix frames as a shift from siloed visibility toward a coherent service topology, where the relationships between components are treated as a first-class, queryable model rather than something reconstructed by hand during a crisis.

Technically, building a real-time map of this kind requires pulling signals from several layers and reconciling them. Netflix appears to draw on runtime data, such as distributed tracing and service-to-service traffic observed at the network or service-mesh layer, alongside more static sources like deployment records and ownership metadata. Runtime observation is valuable because it reflects what is actually happening rather than what documentation claims, capturing dependencies that emerge dynamically, including calls that only occur under specific conditions. Static metadata, in turn, adds context that raw traffic cannot, such as which team owns a service and how it is configured. Merging these streams into a consistent graph, and keeping that graph fresh as deployments change the topology many times a day, is the central engineering challenge.

A topology of this nature is naturally modeled as a graph, with services as nodes and the calls between them as edges. Representing the system this way enables questions that are difficult to answer otherwise: what depends on a given service, what would be affected if it degraded, and which paths carry the most critical traffic. The freshness requirement is what makes the effort demanding. A map that is hours or days out of date can mislead responders, so the system is designed to update continuously as new dependencies appear and old ones fade, keeping the displayed picture close to the live state of production.

This work sits within a broader observability ecosystem and a long history of relevant tooling at Netflix and across the industry. Observability is commonly described in terms of metrics, logs, and traces, and distributed tracing standards such as OpenTelemetry, along with earlier projects like Google's Dapper and the open-source Zipkin and Jaeger, established many of the techniques for following requests across service boundaries. Service meshes such as Istio and Linkerd, and proxies like Envoy, made service-to-service traffic more observable by sitting in the request path. Netflix itself has a notable open-source lineage in this space, including resilience and routing libraries such as Hystrix and Zuul, and its long-standing investment in chaos engineering through tools in the Simian Army tradition. A reliable topology map complements these efforts, giving the data they produce a structural backbone.

The practical payoffs extend beyond incident response. A shared, accurate dependency graph can support capacity planning, help teams understand the blast radius of a proposed change, surface unexpected or unwanted coupling between services, and inform reliability work such as identifying single points of failure. It can also aid newcomers trying to understand an unfamiliar part of the system. These benefits depend heavily on the map being trusted, which is why the emphasis on real-time accuracy is significant; a topology that is perceived as stale or incomplete is quickly ignored.

For other engineering organizations, the account is likely most useful as a pattern rather than a turnkey solution. The specifics of Netflix's data sources and infrastructure are its own, but the underlying lesson generalizes: as microservice estates grow, treating service topology as a maintained, real-time product can reduce the cognitive load of operating distributed systems. The post is best read as a window into how a large operator approaches that problem, including the trade-offs between runtime and static data and the ongoing cost of keeping such a map current.