Netflix's Real-Time Service Map Pipeline

Netflix engineers grappled with the challenge of creating a unified, real-time view of their sprawling service dependencies. Traditional batch processing methods proved inadequate, delivering data too stale for critical incident response. This led to the development of a streaming-first architecture, detailed on the Netflix Tech Blog.

StartupHub data

Companies working on this

Profiles of the companies named in this story, with funding and a one-liner from our database.

Netflix

$4.7B

The world's leading streaming entertainment service.

The core innovation is a distributed service map pipeline designed for scale and real-time updates. This system ingests millions of network flow records and IPC metrics per second, processing them through reactive pipelines with built-in backpressure handling.

Streaming-First for Real-Time Observability

Unlike batch systems that offer hourly or daily snapshots, Netflix’s pipeline continuously ingests data, providing topology updates within tens of minutes. This real-time capability is essential for live events and rapid incident response.

Backpressure is crucial for managing the data flow. When downstream systems slow down, upstream components are signaled to pause, preventing data loss or system crashes. This allows the pipeline to degrade gracefully under load.

A Multi-Layered Approach

The architecture employs physically separate topology layers for network flows, IPC metrics, and distributed tracing. Each layer is optimized for its specific data type and query patterns, offering independent evolution and unified querying.

The Three-Stage Aggregation Pipeline

The network layer ingestion relies on a three-stage distributed aggregation pipeline. This design tackles the complexity of network intermediaries, which obscure direct application-to-application dependencies in raw flow logs.

Stage 1: Initial Aggregation

Flow logs from multi-region Kafka streams are filtered, batched into 5-minute windows, and initial aggregators are created. This stage identifies flows involving intermediaries but doesn't resolve them.

Stage 2: Network Intermediary Resolution

This stage groups flows by intermediary (like load balancers or proxies). By redistributing aggregators based on intermediary identifiers, it joins incoming and outgoing flows to resolve direct application edges, effectively removing network hops from the topology view.

Stage 3: Final Aggregation and Enrichment

Resolved edges are further aggregated, enriched with external data like ownership and health metadata, converted into graph entities, and then persisted to the graph database with throttled writes.

This three-stage process, including a second redistribution step, prevents the creation of 'hot nodes' by spreading the load of resolution and enrichment across multiple instances.

Engineering Challenges and Lessons

The journey involved significant hurdles, including Kafka consumer lag, uneven traffic distribution ('hot nodes'), and memory management issues like garbage collection pauses and persistent heap pressure. Serialization complexity and stream processing inefficiencies also demanded solutions.

The team learned that scale changes everything in distributed systems. Optimizing one bottleneck at a time and recognizing that distribution is key to achieving scale were paramount.

For inter-stage communication, Server-Sent Events (SSE) were chosen over gRPC or message queues due to their lightweight nature, minimal serialization overhead, and natural integration with reactive streams, proving that industry best practices aren't universally applicable.

The IPC pipeline, unlike the network flow log pipeline, requires only a single stage because its data is already correctly partitioned at the application level, eliminating the need for intermediary resolution.