Comment by RadiozRadioz
6 months ago
Dude, you can't have it both ways, pick one. You didn't want load on the DB, so you need to cache things somehow. Dealing with cache invalidation is a natural consequence.
Ok then, keep the DB, provision a distributed array of read replicas, make them use synchronous replication to maintain your atomicity, force them all of them to keep the session table in memory. Now your cache is managed by the DB and meets all your requirements.
I can have it both ways, that is the entire point of the refresh/access token system. The access tokens are used for 99% of requests (every request except "refresh" requests) and I am not persisting them anywhere – there is no cache/db read. It is a quick, CPU-bound check to decrypt the token, no i/o required.
Your newly proposed solution sounds much more complicated than the above.
Ah right, my apologies, I seem to have misunderstood here. For some reason I thought your initial comment was narrowly discussing the issue of DB load in a system that doesn't use refresh tokens.
Upon re-reading the thread context I have no idea why I thought that. Yes of course, refresh tokens are the best solution