Netflix Explains Service Topology: A Real-Time Map for Thousands of Microservices

Netflix engineers found that understanding service dependencies during an incident was painfully slow, since existing metrics, logs, and traces each show only a fragment of the system rather than the full connectivity map. To close this gap, the team built Service Topology, a living dependency map designed to answer three recurring questions: which services depend on each other, what the blast radius of a failure is, and where a problem actually originates.

After analyzing four years of engineering support requests, Netflix found consistent patterns — questions about upstream/downstream dependencies, maintenance impact, unexplained 'unknown' services in dashboards, and recent call-path changes. These recurring needs shaped the system's core requirements: real-time updates, sub-second query performance, and visibility into both network and application layers.

The resulting architecture combines three independent data sources into three separate topology graphs: eBPF-captured network flows, application-layer IPC data, and trace-based request graphs. Each layer is stored separately and can be queried independently or merged into a unified view through parallel traversal queries. The core insight is that no single data source tells the complete story, and combining them yields both accuracy and speed at Netflix's scale.

For engineers, this approach offers a broader lesson in observability design for distributed systems — emphasizing real-time freshness, integration with existing tooling, and multi-source data reliability. These principles are broadly relevant to any team building dependency mapping or incident-response tooling at scale.