Canva Shares S3 Based Architecture for Session Revocation Across Hundreds of Millions of Sessions

Canva’s redesign eliminates a critical bottleneck: every authentication request no longer hits a shared database. Instead, each gateway instance holds a local, in-memory index of revoked sessions. The index is built from immutable S3 objects that are downloaded on demand. This change removes the need for a high-availability database tier dedicated to revocation lookups, reducing infrastructure cost and deployment latency.

The trade-off is operational complexity. Gateways must maintain a sliding 12-hour window of revocation data, split into 30-minute chunks. Each chunk is a sorted array of 16-byte records, enabling fast binary search. Conditional GETs ensure gateways fetch only changed chunks, while conditional PUTs let asynchronous workers merge new revocations without conflicts. The design assumes S3’s eventual consistency is acceptable for revocation propagation, which may not hold for stricter real-time requirements.

Memory savings come from the compact binary format and the use of sorted arrays. A chunk containing one million revocations occupies only 16 MB, making it feasible to keep the entire window in memory. However, the approach stops working if the revocation rate exceeds the worker’s 2,000 revocations per second limit or if the 12-hour window is too short for operational needs. Teams must also handle cache reconstruction during gateway restarts, which relies on S3 availability.

The architecture shifts load from database reads to S3 writes and network transfers. Database load now scales with revocation write throughput rather than the number of gateways, making it more predictable. However, S3 costs and latency become new variables. The design also assumes that gateways can tolerate the delay of downloading new chunks, which may not be true for ultra-low-latency applications. Engineers must validate that the chosen chunk size and window duration fit their traffic patterns.

Canva’s choice of S3 over Redis highlights a preference for durability and operational simplicity. S3 eliminates the need to manage another datastore, but introduces new failure modes, such as S3 outages or throttling. The design also relies on ZooKeeper for leader election, though it is not required for correctness. Teams adopting this pattern must weigh the benefits of reduced database load against the added complexity of managing in-memory indexes and S3-based coordination.