But that is his point.
If you cannot find the session id in redis, you login again.
If your Redis server crash, you start a new one and everyone just login again. No data is lost.
Sure the data is lost. A session commonly holds arbitrary state, and even if it’s just the login information. This is ridiculous.
Obviously these are application decisions.
You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it.
We use redis as infrastructure. To route events and as a cache.
For us redis could go down and we would merely see a degradation of our service with no data loss.
I recommend using redis like that. And then use a database that supports transactions for real data problems.
But we are different. And that's OK.
This discussion is a bit weird. We started off from, Redis should have better availability guarantees. Specifically to avoid the degradation of service you described.
But that requires running on multiple instances, which in turn requires to share the data across all replicas.
If you consider it important, you have to store it in a real database. No buts. If you don't consider it important, sharded redis works fine.
Redis is a real database. If I wasn’t convinced it could retain data I hand it, I wouldn’t use it in the first place.
Just because it works for your use case right now doesn’t mean there isn’t room for improvements to support others too.
> Redis is a real database.
Oh good, then you don't need to do any of the stuff that you suggested to do