Shadow traffic: 2 real scaling case studies

2 of the 94 engineering write-ups in our database are tagged with the technique "shadow traffic". They come from 2 companies (Netflix and Zalando) and were published in 2026. 2 of the 2 state concrete scale numbers, for example "hundreds of thousands of events/sec for one ad break in a single AWS region (load test)" (Netflix). Each card below links to our short summary and the original post.

Netflix · 2026

Behind the Scenes: Evolving Netflix's Ads Event Pipeline for Live, Part II

Netflix's Ads Event Publisher used to enrich each client ad event by looking up metadata the ad server had written to a globally replicated key-value registry. For live events with tens of millions of concurrent viewers, that meant must-succeed database writes on the ad-serving critical path, a store that couldn't safely be scaled mid-event, and late events whenever lookups slowed. Netflix replaced it with an Apache Flink job: the ad server logs its responses to Kafka, and a custom KeyedCoProcessFunction joins them to client events over a 60-minute window, which catches roughly 99.999% of events. An hourly Spark job orchestrated by Maestro recovers the rest from the data warehouse. Revenue-bearing events are de-duplicated in local Flink state keyed by a hashed event ID. Both pipelines ran side by side with automated audits, and a stable per-event key moved publishing to Flink a slice at a time, region by region. When they agreed on well over 99.99% of events, Netflix retired the legacy service and the registry. In a load test, one AWS region handled an ad break at hundreds of thousands of events per second.

hundreds of thousands of events/sec for one ad break in a single AWS region (load test)~99.999% of events joined within a 60-minute windowstreaming joinsdeduplicationshadow trafficFlinkKafkaSpark
Zalando · 2026

From Homegrown to Flink: Migrating a Stateful Ad Event Join at Scale

Zalando Marketing Services replaced a 7-year-old homegrown in-memory join that matched Sponsored Products auction bids to clicks/views within 15 minutes. The old Java service read up to 200 MB/s, could not partition both streams cleanly, and lost up to 15 minutes of state on every deploy or rescale. After Interval Join burned 15-30% CPU on RocksDB seeks and held a ~70M-entry timer queue, they rewrote the match with KeyedCoProcessFunction (point lookups, RocksDB TTL expiry), incremental 3-minute checkpoints, and two-way state. A four-week shadow pipeline hit 99.9% enrichment parity, then a one-week A/B test; average pods fell from 20 to about 5, memory from ~320 GB to ~100 GB, and EC2 cost from about €80 to €30 per day, with enrichment up ~0.5%.

up to 200 MB/s on the old pipelineaverage pods cut from a constant 20 to ~5 (range 1-8)stream joinscheckpointingkeyed stateApache FlinkRocksDBKubernetes

Get new shadow traffic scaling stories weekly

One email a week. No spam.

Companies in these stories

Browse all 105 topics →