What would be the point of embedding Redis into an application? What's the advantage of using Redis over using the builtin (or third party) data structures of the language the application is developed in?

I'm asking as a non-webdev who never quite got what Redis actually does, but would love to learn.

> One, it would be cool to be able to embed it, similar to sqlite, directly into applications.

I've found myself wanting this on several occasions too. I.e. wanting all my rust backend processes (k8s pods) to have some minimal shared state, without having to spin up a Redis cluster. I've talked to Claude about it a couple of times, and it descends into something like, "you gotta use Raft or CRDTs, and pick 2 out of 3 from CAP". Which honestly seems pretty fair, and indicates to me that I'm dreaming for something magical.

Nonetheless, it is nice to hear someone else asking for this. If this is indeed feasible (even if simple/limited), then I'd be interested to try it.

Genuinely interested why we need HA in redis, just not read round robin from multiple non-HA instances? Redis (and memcache) are memory caches and should be treated like that, not like highly consistent distributed session store.

> it's still lacking in two areas

This is entirely different than what Redis is and tries to solve.

Sqlite is embedded. It's not a distributed SQL. Redis is a distributed data structure store and concurrency primitive. These are worlds apart.

> HA story is so much more complicated than it should be

It is precisely as complicated as it needs to be. You don't want data loss.

If you're in the business of high available fault tolerance, you read the manual and learn how to Redis.