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.

No two processes can guarantee data consistency unless using shared memory with some kind of locking on update. And given two servers don't share memory, two processes running on these servers can not guarantee consistency either.

To put the simple terms... App writes to node-A, node-A (/process on node-A) crashes before change is synced from node-A to node-B, data is lost.

This is true for redis and true for postgresql/ mysql or any similar database. Difference between redis and a "database" is that database protects against this problem by writing change to durable storage before telling app that write is successful. Redis

So if one wants to have a consistent session storage, one should use a proper database or use AOF redis persistense with single node (https://chatgpt.com/s/t_6a24ab818e2881918db959cec8d8cc2d)

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

No, redis is a memory cache, with some ACID like features bolt on.

Even real databases have hard time maintaining consistency across nodes. CAP is a real constraint.

> Redis is a real database.

Oh good, then you don't need to do any of the stuff that you suggested to do

These two concerns are not mutually exclusive, the kind of database or data stored within it doesn't give any availability guarantees on its own. Even a single Postgres instance, which I suppose fits your understanding of a real database, is a single point of failure and not a highly available setup: If your database server goes down, clients get errors and the database is thus unavailable.

I don't think you understand what HA means.

The app would look up in both databases. If it exists in any, there would be a session.

Thisnis strictly different from partitioning which I think you are mixing it up with.

Paritioning is for performance not HA

> The app would look up in both databases. If it exists in any, there would be a session.

And if you find the session with differing values in both databases, how do you know which one is up-to-date?

You need an algorithm to pick which data is right, such as electing a master instance.

And that brings us back to the original discussion: to manage sessions (unlike caches) in a highly available way, you need to setup HA (or reimplement it, which obviously is a bad idea). You can't read round robin from multiple non-HA instances.

Yes, you are pointing out exactly how HA is difficult.

There is a whole slew of downstream things you need to take into consideration.

and as you've just confirmed... there is a need for good HA support in Redis. Which was the entire premise of this thread.

That’s the precise point I’m making