How teams scaled Kubernetes: 10 real case studies
10 of the 94 engineering write-ups in our database mention Kubernetes in their stack. They come from 6 companies (Zalando, Datadog, OpenAI, Netflix, PlanetScale and 1 more) and were published between 2020 and 2026. Techniques that show up most often alongside Kubernetes: autoscaling (2), caching (2), synchronous replication (2) and workload isolation (2). It's often paired with PostgreSQL (4), Java (2) and Patroni (2). 9 of the 10 state concrete scale numbers, for example "one primary and multiple replicas per shard" (PlanetScale). Each card below links to our short summary and the original post.
Designing a planned switchover for minimum disruption
When a Neki shard's primary has to step aside for a pod replacement, kernel upgrade or cell move, PlanetScale does a planned switchover instead of stopping Postgres the way Patroni does, so a failed switchover can quickly fall back to the old primary. Admin, Neki's control plane, first validates shard state, the target replica, logical failover slots and Postgres settings. Routers then proactively buffer primary-bound queries, the primary defaults new transactions to read-only, and the other replicas are disconnected to pin a final WAL position the target must replay. If the target can't catch up before a deadline, a config reload makes the old primary writable again. Buffered queries are replanned against the new primary, so apps see added latency instead of errors, and every acknowledged commit is on the target when it is promoted.
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.
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%.
Client-Side Load Balancing at a Million Requests Per Second
Zalando moved the internal fan-out of its Product Read API off the shared Skipper ingress into an in-process JVM load balancer that rebuilds the same xxHash64 consistent-hash ring. They added N-ring fade-in so new pods warm only the products they will keep, bounded load based on occupancy (Little's Law) weighted by latency, and a capped ring walk. Pods ran more evenly, the autoscaler target rose from 50% to 65% CPU, and the fleet shrank by over 25%.
When failover isn't safe: Building high-availability PostgreSQL on Kubernetes
A gameday that injected network latency into one availability zone left several of Datadog's Kubernetes-based PostgreSQL clusters stuck: replicas lagged past Patroni's maximum_lag_on_failover, so no standby could be promoted safely. Datadog moved to a hybrid model: standbys in the leader pool take part in synchronous replication (one synchronous standby, synchronous_mode_strict, synchronous_commit=remote_apply) while read replicas stay asynchronous. pgbench showed remote_apply raised average latency by 53% and cut throughput by 34%, yet production clusters saw no measurable impact after a gradual rollout, and synchronous replication is now enabled in all of its clusters.
How OpenAI delivers low-latency voice AI at scale
OpenAI rebuilt its WebRTC stack for ChatGPT voice and the Realtime API after one-port-per-session media termination collided with Kubernetes: large public UDP ranges, sticky ICE/DTLS ownership, and global first-hop latency. A lightweight Go relay exposes a small fixed UDP surface, reads ICE ufrag routing hints from the first STUN packet, and forwards opaque media to the transceiver that owns ICE, DTLS, and SRTP state (with Redis-backed recovery). Cloudflare geo and proximity steering place signaling near users while Global Relay shortens the first media hop, preserving standard WebRTC for clients without making inference backends WebRTC peers.
Scaling PostgreSQL to power 800 million ChatGPT users
OpenAI runs ChatGPT on a single-primary Postgres with nearly 50 global read replicas. Reads are offloaded, write-heavy shardable workloads move to Cosmos DB, and PgBouncer, cache leasing and multi-layer rate limits keep the primary safe.
Contributing to Debezium: Fixing Logical Replication at Scale
Zalando's Fabric Event Streams provisions Debezium-in-embedded micro-apps so teams declare Postgres-sourced Kafka streams on Kubernetes; at peak the connectors handle hundreds of thousands of events per second across 100+ clusters, and have processed billions of events since 2018. Uncontrolled WAL growth on low-activity databases was the top operational issue until a pgjdbc keepalive flush advanced replication slots without table traffic. When newer Debezium hard-disabled that flush, Zalando contributed lsn.flush.mode (including connector_and_driver) and offset.mismatch.strategy (including trust_slot / trust_greater_lsn) so operators can opt into keepalive flushes while choosing whether the slot or the offset store wins on restart—both shipped in Debezium 3.4.0.Final.
Achieving relentless Kafka reliability at scale with the Streaming Platform
Datadog treats Kafka as commodity hardware behind a Streaming Platform control layer. Streams span multiple Kafka clusters, AZs, and Kubernetes clusters so producers and consumers talk to stable identifiers while the control plane redirects traffic to healthier topics in seconds—for incidents, rebalancing, decommissioning, or repartitioning—without app redeploys. A custom Assigner replaces Kafka's group coordinator for multi-cluster rebalancing in seconds; Stream lanes isolate QoS and park poison pills in a DLQ; an enriched commit log tracks multiple offset ranges plus timestamps so consumers can process live traffic while replaying backlogs and the control plane can compute wall-clock lag across millions of partitions. After zstd "bombs" crashed stock clients, Datadog wrote libstreaming in Rust (with Java/Go/Python bindings) for unified, high-throughput access without a proxy in the TB/s data path.
Capacity Planning at Scale
How Shopify plans and checks capacity for traffic peaks like BFCM using forecasts and scalability tests.