Netflix restructured the pipeline for Service Topology to ensure the real-time service map remains useful at production scale. The key question here is not about processing speed, but how to maintain relevance, integrity, and manageable degradation.
Service Topology at Netflix is built on several sources: eBPF network flows, IPC metrics, and distributed traces. This provides a more complete dependency map but also creates a complex challenge at the ingestion pipeline level. Raw flow records show network hops, not the logical connections between applications. Therefore, the system must not only accept the data but also interpret it and restore its meaning.
The problem manifests in hot paths. Popular destinations create load concentration, and intermediary resolution requires gathering related flows in one place. In the old scheme, this led to hot instances. Netflix describes cases where individual nodes received up to 100 times more typical traffic while simultaneously performing I/O-heavy enrichment. Against this backdrop, the service begins to degrade not along one axis, but across several: pressure on compute, storage, and memory pressure increases.
The solution turned out to be architectural rather than cosmetic. Netflix divided the pipeline into three stages: initial aggregation, intermediary resolution, and graph persistence. This division separates the heavy interpretation of flows from enrichment and writing to the graph. It is a compromise, but a pragmatic choice. It complicates the pipeline itself but reduces the risk that one stage becomes a bottleneck for the entire system.
The first stage reads multi-region Kafka streams, filters invalid records, collects data in five-minute windows, and builds initial aggregators. The second stage transforms intermediary hops into direct application-to-application edges and redistributes the results. The third stage enriches nodes with data about health, ownership, and metadata, and then saves them in a graph database. This order is important: first, the meaning of the connection must be restored, and only then should resources be spent on enrichment and persistence.
In its implementation, Netflix also changed the transport between stages. Instead of gRPC within the pipeline, server-sent events are used. According to the company, gRPC became costly at this scale due to serialization, connection-pool management, and memory pressure on streaming responses. SSE turned out to be lighter and better aligned with reactive backpressure. At the same time, the gRPC API for Service Topology clients has been preserved. This is an important detail: internal transport can be simplified without affecting the external contract.
A separate layer of engineering discipline here is backpressure. Netflix uses Apache Pekko Streams to propagate pressure up the chain. If graph storage cannot keep up, the Kafka consumer does not attempt to endlessly push data further. It stops and leaves records in Kafka until capacity becomes available. This means that the system opts for delayed freshness instead of data loss. For incident response, this is safer behavior than an incomplete dependency map that only appears current at first glance.
The scaling mechanism is also interesting. The processing fleet expands and contracts based on demand. Each instance reads the current list of healthy instances from the service registry and applies consistent hashing to determine the owner of each aggregator. When an instance is added or removed, only the affected aggregators move to new nodes. This eliminates a separate rebalancing process and makes distribution more localized. For such a system, this is a sensible way to keep overhead under control.
At the same time, the IPC pipeline is simpler. Its metrics are already partitioned by application, so it does not require the same heavy redistribution stage. This illustrates an important architectural principle: the same processing model does not have to fit all data sources. Complexity should follow the data structure, not the desire to unify everything for convenience.
Finally, Netflix describes historical reconstruction of the topology. Instead of storing complete graph snapshots or replaying event logs, the system maintains time-windowed aggregator snapshots and property-level mutation history. This allows for the restoration of topology at a specific point in time. For incident investigation, this is particularly valuable because dependencies change not only in the current state but also around events. Here, another compromise is visible: the company does not store everything indiscriminately but retains enough data to reconstruct the past on demand.
In summary, Netflix demonstrates a mature production approach. The system does not attempt to be instantaneous at any cost. It accepts freshness delays to avoid data loss and maintain the integrity of the dependency map. For architects, this is a useful benchmark: a real-time observability pipeline should be not only fast but also predictable under load.