How teams scaled Java: 4 real case studies
4 of the 73 engineering write-ups in our database mention Java in their stack. They come from 4 companies (Canva, LinkedIn, Slack and Zalando) and were published between 2016 and 2026. Techniques that show up most often alongside Java: caching (2), consistent hashing (2) and fan-out (2). 2 of the 4 state concrete scale numbers, for example "hundreds of millions of users" (Canva). Each card below links to our short summary and the original post.
Session revocations at scale
Canva keeps 12 hours of session revocations in memory on every gateway, but hundreds of pods each loading over a million revocations from MySQL on deploy caused a stampede on the database. A worker now packs revocations into sorted 16-byte records in 30-minute chunks on S3, using conditional PUTs for optimistic concurrency and ZooKeeper leader election to avoid conflicts, and reaches over 2,000 revocations per second. Gateways binary-search the downloaded bytes directly and poll with conditional GETs, which shrank the cache by 87.5% and cut the revocation database down to two read replicas kept for redundancy.
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%.
Real-time Messaging
An overview of Slack's channel and gateway servers that fan messages out to millions of connected clients in real time.
FollowFeed: LinkedIn's Feed Made Faster and Smarter
LinkedIn moved its feed to a fan-out-on-read system that keeps member timelines in memory and on RocksDB.