Staged rollout: 2 real scaling case studies

2 of the 94 engineering write-ups in our database are tagged with the technique "staged rollout". They come from 2 companies (Grab and Netflix) and were published in 2026. 2 of the 2 state concrete scale numbers, for example "millions of lines of Android code" (Grab). Each card below links to our short summary and the original post.

Grab · 2026

App stability at scale with a layered defense

With many engineers and AI-assisted code landing in a weekly release of a superapp that has millions of lines of Android code, Grab stops crashes in layers. Lint rules (including custom ones written after post-mortems) and tests block merges, a mandatory one-week Grab Early Access build catches crashes before production, and a staged rollout over a week is automatically paused when the new version's crash rate looks abnormal. In production, on-call engineers first flip feature flags, then try server-side fixes, then hotfix, helped by a flag-rollout history dashboard and Crashlytics data exported to BigQuery.

millions of lines of Android code100M+ Google Play downloadsshift-left testingstaged rolloutfeature flagsAndroidiOSFirebase Crashlytics
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

Get new staged rollout scaling stories weekly

One email a week. No spam.

Stack in these stories

Companies in these stories

Browse all 105 topics →