Comment by RadiozRadioz
6 months ago
Then don't hit the SQL DB directly, cache the tokens in memory. Be it Redis or just in your app. Invalidate the cache on token expiry (Redis has TTL built in).
UserID -> token is a tiny amount of data.
6 months ago
Then don't hit the SQL DB directly, cache the tokens in memory. Be it Redis or just in your app. Invalidate the cache on token expiry (Redis has TTL built in).
UserID -> token is a tiny amount of data.
And now I need to invalidate the cache if the key is invalidated. Also this cache cannot be updated/invalidated atomically, like I can if I'm just storing a refresh key in the SQL db. Caching in Redis is more complex and more prone to error than access/refresh token systems.
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.
1 reply →