When you press play on Netflix, that single action triggers a cascade of service-to-service calls: authentication, recommendations, video encoding selection, playback optimization, and more[reference:39]. Engineers at Netflix needed a unified, real-time view of these service dependencies to troubleshoot faster, understand blast radius, and navigate their distributed architecture[reference:40].
A Multi-Source Approach
Netflix built Service Topology using three complementary data sources to build separate dependency graphs that can be combined into a unified view or explored independently[reference:41]. The network layer uses eBPF flow logs for comprehensive coverage. The IPC layer uses application metrics with rich endpoint details. The tracing layer uses distributed traces for actual request paths[reference:42].
Physical storage isolation enables independent optimization. Each layer has different throughput, query patterns, and evolution timelines. At query time, the system executes parallel queries across relevant storage systems and merges results, providing unified views with sub-second latency[reference:43].
The Streaming Pipeline
Traditional service topology systems use batch processing, aggregating data hourly or daily. Netflix took a streaming-first approach, continuously ingesting flow records and providing near real-time topology updates within tens of minutes[reference:44].
The network layer ingestion uses a three-stage distributed pipeline. Stage 1 consumes flow logs from multi-region Kafka and batches them into 5-minute time windows. Stage 2 resolves network intermediaries like load balancers and NAT gateways into direct application edges. Stage 3 performs final aggregation and persists to the graph database.
Backpressure and Resilience
At Netflix scale, backpressure isn't optional, it's the mechanism that keeps the system running reliably[reference:45]. When downstream stages can't keep up, they signal upstream to slow down. The data waits in Kafka until capacity returns. No data is lost, no instances crash, the system degrades gracefully[reference:46].
Production Challenges
The first version worked perfectly in the local environment but failed in production. Kafka consumers fell behind. Instances ran out of memory. Some nodes received 100 times the traffic of others. Garbage collection pauses consumed more CPU than business logic.
The solution involved multiple optimizations: increasing Kafka partitions and fetch sizes, splitting responsibilities into three stages to prevent hot nodes, moving from immutable to mutable data structures on hot paths to reduce GC pressure, and replacing gRPC with Server-Sent Events for inter-stage communication.
Time-Travel Queries
One of the most powerful capabilities enables querying historical topology: engineers can ask what the call graph looked like when an incident happened. The system stores aggregator states every 5 minutes and maintains mutation history at the property level. When querying historical topology, the system retrieves all mutations and reconstructs the state by applying them in order[reference:47].
Service Topology now processes flow logs, IPC metrics, and traces from multiple regions, serving queries with sub-second latency. Teams across Netflix use it daily for incident investigation, blast radius analysis, dependency understanding, and production change management[reference:48].