Scaling a system to handle hundreds of millions of active sessions is the kind of problem most engineering teams only face in nightmares. So when Canva shares its architecture for session revocation, we pay attention. The core challenge is straightforward: when a user logs out or a token is compromised, you need to invalidate that session everywhere, immediately. Do it wrong, and you either accept a security gap or hammer your database into submission with constant lookups. Canva's answer, as detailed in their recent post, is a two-tier approach that leans on Amazon S3 for durable records and compact in-memory indexes distributed to application gateways. It's a pragmatic design that prioritizes consistency without pretending every gateway can hold every session ID in RAM.
The most striking number here isn't the 100 million active sessions, though that is impressive. It's the 87.5% reduction in revocation cache memory footprint. That is the kind of efficiency gain that lets a team sleep at night, not because they bought more hardware, but because they redesigned the data flow. For our readers, the practical takeaway is about separation of concerns. Canva separated the durable, source-of-truth record (S3) from the hot, frequently-accessed lookup surface (in-memory indexes). That is not a revolutionary idea, but it is an elegant one, and it works because they decoupled the cost of storage from the cost of speed. If you are building for scale, you should ask yourself: where is my bottleneck? If it is the database, can you move that hot path closer to the edge, even if it means accepting eventual consistency in a controlled way?
What we appreciate most about this story is what it does *not* say. There is no mention of a "game-changer" or a "paradigm shift." Instead, Canva offers a concrete, boring-in-the-best-way solution to a hard problem. That is the mark of an engineering culture that values clarity over hype. For a reader wrestling with similar issues, the question to consider is not whether S3 is the right choice for you, but whether your revocation model can tolerate the latency of a distributed index. Canva's design works because they could accept that a revoked session might linger for a few seconds in a gateway cache. That trade-off is not universal. If you are working on a system where a revoked session must be rejected instantly, you will need a different pattern.
The detail we are watching is the deployment speed improvement. Canva said the new architecture improved deployment speed, which suggests the previous system had become a bottleneck in itself. That is often the silent killer: the system works, but it makes the team slow. If you are reading this and your session management is becoming a constraint on your release cadence, you have your answer. The takeaway to quote: **"Reducing the memory footprint by 87.5% is impressive, but the real win is that Canva turned a scaling problem into a design principle: separate the durable truth from the fast path."** That is the lesson worth stealing. The open question is whether your team is willing to make the same trade-offs Canva did, or if you will wait until 100 million sessions force your hand.