Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned

Summary

Engineers at Netflix required a unified, real-time view of service dependencies to navigate distributed architecture and improve incident troubleshooting. Traditional batch systems introduced stale data, so the team created a streaming-first platform backed by reactive streams and backpressure handling to ingest flow records from multi-region Kafka streams and Server-Sent Events without data loss. The architecture partitions data into physically separate graph and columnar storage layers covering eBPF network flows, IPC metrics, and distributed traces. Network flow ingestion relies on a three-stage distributed aggregation pipeline using consistent hashing to resolve network intermediaries into logical application connections. The resulting production system serves time-travel and topology queries with sub-second latency while continuously updating dependency views.

Context

Engineers at Netflix needed a unified, real-time view of service dependencies across distributed architecture to troubleshoot incidents faster and understand blast radius, whereas traditional batch-processing approaches yielded hours-old or day-old dependency maps.

Approach / What changed

Netflix implemented a streaming-first architecture with backpressure handling across separate storage layers for eBPF network flows, IPC metrics, and distributed traces. A three-stage distributed aggregation pipeline ingests multi-region Kafka streams, batches flow logs into 5-minute windows, and resolves intermediate hops into logical service dependencies.

Takeaways

• Reactive streams with backpressure propagation allow the ingestion pipeline to slow upstream stages and Kafka consumers during load spikes without crashing instances or dropping records.
• Physical storage isolation across network flow graphs, IPC metric graphs, and Parquet trace storage enables independent optimization for differing throughput and query patterns.
• Multi-stage aggregation with redistribution at each stage prevents single-instance bottlenecks caused by power-law traffic distributions.

Related reading

• Netflix · Aug 7, 2026

  How and Why Netflix Built a Real-Time Distributed Graph: Part 3 — Querying the graph with gRPC…

  Netflix designed a query execution serving layer for its Real-Time Distributed Graph to power sub-100ms responses across diverse graph traversal workloads spanning billions of nodes and edges. To prevent compounding network delays in multi-hop queries, the engine uses a breadth-first traversal model that batches entity lookups across entire frontier levels rather than tracing paths depth-first. The entire serving architecture relies on asynchronous composition across small thread pools of 16 to 24 threads, ensuring no thread blocks while waiting on remote storage or enrichment I/O. Selective caching via EVCache targets stable properties with volatility-matched TTLs, producing 70 to 80 percent cache hit rates and reducing backend storage calls by three to four times. A layered filtering hierarchy pushes depth and edge limits directly to the storage tier, eliminating bespoke code changes while isolating system resources against excessive fan-out.

  Netflix Technology Blog

• Grab · Jul 7, 2023

  Zero traffic cost for Kafka consumers

  Grab's real-time data streaming platform team reduced infrastructure expenses by enabling Kafka consumers to fetch from the closest partition replica instead of partition leaders. The platform previously operated across three AWS Availability Zones with three-way replication, resulting in cross-AZ network fees that constituted half of the Kafka platform's total cost. To address this, the team performed a zero-downtime upgrade to Kafka 3.1, configured a rack-aware replica selector using AWS Availability Zone IDs, and updated consumer SDKs to populate the client rack parameter. The rollout produced a 25% drop in cross-AZ traffic within three months under steady data volumes. However, the change increased end-to-end latency by up to 500ms, created potential CPU load skews across zones, and removed graceful isolation during broker rotation maintenance.

  Fabrice Harbulot

• Grab · Mar 3, 2019

  How We Simplified Our Data Ingestion & Transformation Process

  Grab evolved its real-time data ingestion pipeline after an initial architecture built on Spark Streaming and Python encountered operational complexity, node failures, and data loss from S3 eventual consistency. Because the streaming workload primarily handled event partitioning and ORC file generation, the team consolidated these tasks directly into an existing Golang processing service. They implemented sharded concurrent maps for high-throughput partitioning and optimized heap allocations to resolve memory bottlenecks. This refactor removed intermediate Avro conversions and intermediate storage hops. The simplified Go pipeline eliminated data loss and reduced processing lag from up to 13 minutes down to approximately 1 minute.

  Yichao Wang

• Grab · Jan 16, 2019

  A Lean and Scalable Data Pipeline to Capture Large Scale Events and Support Experimentation Platform

  Controlled online experimentation across diverse product verticals requires tracking interactions across systems to prevent local optimizations from causing global degradation. Grab built a batch data pipeline to capture, ingest, and process petabytes of event data to support its experimentation platform and analytics stakeholders. The architecture loads ingested event data from Amazon S3, transforms and sorts it, and writes partitioned output back to S3 with metadata registered in Apache Hive. Using Apache Spark on AWS Elastic MapReduce with Apache Airflow for orchestration, the system handles roughly 400,000 incoming events per second. The data is partitioned by event type and ingestion time and stored in Apache ORC format to streamline query workloads and reduce retrieval overhead.

  Oscar Cassetti