Canva

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.

Published
2026-07-22
Scale
hundreds of millions of users, hundreds of thousands of session checks/sec, 2,000+ revocations/sec write throughput, 87.5% smaller in-memory cache
Techniques
caching object storage optimistic concurrency control binary encoding
Stack
MySQL Amazon S3 ZooKeeper Java

Try this stack yourself

  • Railway · Deploy something like this on Railway: spin up MySQL plus your app in a few clicks. New accounts get $20 in credit (applied when you pick a paid plan).
    Railway isn't part of Canva's setup in this story. It's just an easy place to try the same building blocks.

Some links above are affiliate links: if you sign up, How They Scaled may earn a commission at no extra cost to you. We only list tools that fit the stack in the story.

See also

Redis vs MySQL at scalePostgreSQL vs MySQL at scale

The best scaling write-ups, weekly

One email a week. No spam.

Open subscribe page

Related stories

Cloudflare · 2026

Inside Hyperdrive: How we solved a rare Hyperdrive MySQL caching bug

Hyperdrive, Cloudflare's distributed connection pooler for Workers, keeps warm database connections on its network and can cache common query results in the CDN cache. Taking its MySQL support from beta to GA meant finding bugs like utf8 being a 3-byte alias (fixed with utf8mb4) and COM_RESET_CONNECTION silently resetting the charset to the server default. The hardest was an empty-result bug seen by the highest-volume MySQL customer in about 0.001% of queries, only with caching on. Each Hyperdrive instance has a Client node next to the Worker and an Endpoint node near the database, and they share a cache when they run in the same data center. Because drivers like Node's mysql2 don't support CLIENT_DEPRECATE_EOF, the Client rewrites results into the Worker's capabilities, so the two nodes were caching different bytes for the same query and could read each other's entries. Caching one canonical encoding no matter which node stores it fixed the bug, and Client connection success reached 99.99%.

99.99% production availability targetbug hit ~0.001% of queriesconnection poolingcachingprotocol translationMySQLWorkersHyperdrive
Zalando · 2026

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%.

1 million+ requests/sec moved off shared ingressup to 100 downstream calls per batchload balancingconsistent hashingcachingJavaKubernetesSkipper
Meta · 2013

TAO: The power of the graph

TAO is Facebook's geo-distributed graph cache over sharded MySQL, serving the social graph at more than a billion reads per second.

over 1 billion reads/secmillions of writes/seccachinggeo-distributiongraph data modelMySQLMemcache
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