Zalando architecture: how Zalando scaled (3 case studies)
We track 3 public engineering write-ups by Zalando, published between 2025 and 2026. They cover autoscaling, caching, checkpointing and consistent hashing. Stack mentioned most: Kubernetes (3) and Java (2). 3 of the 3 state concrete scale numbers, for example "up to 200 MB/s on the old pipeline". Each card below links to our short summary and the original post.
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%.
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.