The cache invalidation based on the data source which that particular report uses. E.g. : If the report is for sales with particular filter. There can be a new sales entry. Now we invalidate cache & the report query run once again cache it. when will you increment the cache counter in the redis? when every you setting a new value for that particular key which already cached. We increase the version counter. so cache miss would happen on next request which warm the cache up again.

Thank you so much for the detailed insight I completely agree, 200%. You’re absolutely right that using a server-side counter misses the causal ordering problem. I initially assumed NTP sync would help, but generating the Lamport clock at the SDK level makes more sense though it adds complexity with restarts and new instances. For now, I’m leaning toward using a Redis-based monotonic counter on the client side to simplify state management, while being mindful of Redis as a single point of failure.

Uva Prasaath Try to add MFA & Auto token invalidation after certain time. If you have more time. MFA - options security questions T-OPT Push notification to device

The findings are great. This is what happens even on SSO with some more controls. Under the hood, the same things are happening. Even the session uses a session cookie to maintain a session.

I am not sure. You could also consider a rate-limiters based on the unique IP. It could prevent you from system outage.

A thought full content Uva Prasaath

Uva Prasaath Yes. That's right. But if we want to design a highly scalable system. We want to make our services stateless. So, we can scale it independently without any walk around.

It's really a thoughtful article. I want to add more information to solve the shared memory problem in the authentication context. We can use the JWT token to ensure only legitimate users can access it. We don't want to maintain session ID on any kind of database or on the server. Still, we need to maintain a refresh_tokens on the server.IT can be done by Redis to build a highly scaleable system.

Really a good analogy used for explaining ports on the computer. Great work.

Thanks dude.