[zandl]

It’s largely irrelevant because the revocation bloom filters are cached on each service, and if the auth service is down then tokens can’t be revoked anyway so the list is still accurate enough.

TBH I don’t think the author of the article has expirenced the nightmare that is a hot session store at a large scale before, you end up with needing to troubleshoot IO latency issues with basically no tooling that can show you where the problem is and you’re up against the hardware limits and what ever black box your cloud provider has made. Where as with JWT everything happens in normal user space and can be reasonably reasoned about with a bit of complexity without razor thin latency deps on IO performance.

[mdavidn]

I'm confused by your comment. Session stores seem like the easiest storage to scale horizontally. The workload is just a distributed hash, _maybe_ with atomic updates. "Three nines" durability over one day is perfectly acceptable. Use a consistent hash ring, no replication, and add nodes until you achieve the performance required.

[zandl]

It’s easier if you have one lookup key for a session, but often that’s not sufficient, consider the case of termination of a session by email address or by a session id. The other issue is you still have every service making high rates of network calls that require low latency since they’re often inline with the UX. So you’re relying more on a chain of IO between services which is nearly impossible to performance troubleshoot with today’s tooling.