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
Netflix · 2026
Single-tenant Titus: VM-level isolation on a multi-tenant container platform
Titus, Netflix's Kubernetes-based container platform, launches millions of containers a week on tens of thousands of EC2 instances, packing many teams onto shared hosts. cgroups can't fence last-level cache, memory bandwidth or the global lock in HTB network shaping, so a small-packet flood from one container could starve its neighbors, and stateful streaming jobs like Flink would fall behind and need minutes to catch up. After ruling out microVMs (Firecracker, Kata), gVisor and moving teams to plain EC2, Netflix added an allowlisted single-tenant mode: the federation layer tags eligible tasks, the autoscaler launches the smallest instance that fits each one just in time, and anti-affinity, taints, no preemption and no repacking keep it alone on its host, all behind the same Titus API. Flink, streaming connectors and telemetry pipelines now report stable operation, and the shared fleet packs more densely because sensitive workloads no longer need anti-affinity spreading. The cost is slower launches, since every task waits for its own instance, and fixed host overhead that can take tens of percent of a small node.
millions of containers launched per weektens of thousands of EC2 instances across multiple AWS regionsworkload isolationmulti-tenancyautoscalingTitusKubernetesAWS EC2
OpenAI · 2026
Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)
OpenAI's Habitat storage platform went from one shared Azure Cosmos DB container, to dedicated single-tenant containers that pushed capacity planning onto every product team, and back to a shared container by default once Azure added hot-key throttling, request-priority QoS and a new serverless mode where each physical partition scales to 10K RU/s and splits on RU usage. After failover and failback outages in late 2024, OpenAI and Azure now co-own testing and monitoring. Replicating small latency-critical datasets widely, a Valkey lookaside cache invalidated through the Cosmos DB change feed, and a Rust rewrite of the proxy cut global read p50 from about 120 ms to about 10 ms.
1B+ users across 40 regions500+ PB served by Habitatmulti-tenancyhot key throttlingCDC cache invalidationAzure Cosmos DBValkeyKafka
Cloudflare · 2026
Origin Range Requests: Serving large files without range-request tuning
Cloudflare's old range-request caching sliced files into a per-zone configured range size, so a small video seek could pull 128 MiB from origin for R2, while small ranges caused floods of tiny origin requests and memory pressure, and concurrent requests in the same range blocked each other. Moving from nginx to its Pingora-based cache, it reused Pingora's fixed-size on-disk chunks as the unit: a coordinator serves cached bytes, attaches to in-flight downloads, fetches only missing chunk-aligned ranges from origin, and validates size and ETag before composing one 206 response. For R2, p99 time to first byte dropped by about half, and letting one response combine disk and upstream bytes cut tiered cache traffic about 6% week over week.
R2 p99 time to first byte roughly halved (hits and misses)~6% less tiered cache traffic for R2-like workloads, petabytes/daycachingrequest coalescingtiered storagePingoraR2Tiered Cache