While I love Redis as a versatile tool for external data structures, it's still lacking in two areas IMHO:
One, it would be cool to be able to embed it, similar to sqlite, directly into applications.
Two, the HA story is so much more complicated than it should be. I totally acknowledge that concurrency and distributed computing is hard, but it should not require reading heaps of documentation and understanding two entirely separate multi-node approaches only to figure out there are lots of subtle strings attached that make it impractical for many applications.
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.
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.
Redis doesn't necessarily have to be used as a cache. Streams, for example, make it a great message queue; but a single-node message queue is a single point of failure and thus not viable for many setups.
We use almost exclusively Valkey now, mostly because we host on AWS and Render, which both use Valkey. It's faster, cheaper and compatible. I'd consider Garnet too but I believe it doesn't support LUA(or didn't at the time we needed it).
There's also a separate blog post that goes into the details of why existing data structures Redis already supported, which could provide array-like behavior, weren't good enough:
While I love Redis as a versatile tool for external data structures, it's still lacking in two areas IMHO:
One, it would be cool to be able to embed it, similar to sqlite, directly into applications.
Two, the HA story is so much more complicated than it should be. I totally acknowledge that concurrency and distributed computing is hard, but it should not require reading heaps of documentation and understanding two entirely separate multi-node approaches only to figure out there are lots of subtle strings attached that make it impractical for many applications.
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.
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.
Redis is used for plenty of things, not just memory caches.
For example if you use it for session storage, you can't have your application read from a random instance that may or may not contain the session.
Redis doesn't necessarily have to be used as a cache. Streams, for example, make it a great message queue; but a single-node message queue is a single point of failure and thus not viable for many setups.
Years ago I enabled durability on redis & used it as database for an online card game
Where did everyone end up on the Redis/Valkey split? Is there still a reason to use Redis after the license kerfuffle?
For those who may not know, you can cut your costs in AWS by going with Valkey over Redis for about 33% savings.
https://aws.amazon.com/blogs/database/reduce-your-amazon-ela...
But what about Geico?
We use almost exclusively Valkey now, mostly because we host on AWS and Render, which both use Valkey. It's faster, cheaper and compatible. I'd consider Garnet too but I believe it doesn't support LUA(or didn't at the time we needed it).
We went with DragonFlyDB
There's also a separate blog post that goes into the details of why existing data structures Redis already supported, which could provide array-like behavior, weren't good enough:
https://redis.io/blog/diving-deep-into-rediss-new-array-data...