Sure the data is lost. A session commonly holds arbitrary state, and even if it’s just the login information. This is ridiculous.
replyObviously these are application decisions.
replyYou, 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.
replyBut 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.
replyRedis 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.
replyJust 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.
replyOh good, then you don't need to do any of the stuff that you suggested to do