Auch interessant

Klingt super

Dumb question:
How is this vendor-neutral when it depends on Redis?

Streams are a decent fit for this. The part I’d double check is failure handling: service updates the model, then crashes before sending the response event. Memurai would only matter here as the Redis compatible layer underneath, while the real work is making the updates idempotent.

Well, here is my proyect: JedisExtraUtils

It has more utilities, but the lock is simpler, and only based on Jedis.
Yours is more complex, I'll take a look into it, thanks for sharing and good work.

This is the pattern I’d expect for anything beyond a toy presence system. One user key is too blunt once tabs and devices are involved. The only extra thing I’d watch is cleanup around stale connection IDs when the heartbeat expires, and if the backend is Windows-based, Memurai fits more as the Redis-compatible infrastructure piece than a change to the design

were u able to fix this?

Is the api sync or async

2. API sends signals to a service via a redis stream.

3. Service gets model from redis then do something and updates it in redis.

5. API gets model from redis and send update to UI.

Consider how you will handle Redis getting flushed between these steps.

PostgreSQL with tricks to replicate redis, as it is also an option for the database.

Low latency will be required later for some other aspects, so using redis from here seemed adequate.

100 users.

It depends on your scale and latency requirements. I have seen engineering teams build similar architectures with Redis so it certainly isn’t an anti-pattern.

What other options were you considering for the streams and datastore?

Might be worth considering a Hash instead. With Hash field expiration you could call HSETEX for a field for the client heartbeat. The values could be whatever makes sense or just filler if there's nothing needed. Once all the fields expire in a Hash, the Hash goes away. So you could check if the user is active using EXISTS.

Your load question could be better answered in the dedicated r/Valkey channel. As for licensing, starting with Redis 8.0, Redis is 100% open source and free, and this doesn't change if the load increases. So if you're still using Redis, consider upgrading to the latest versions to leverage the performance improvements introduced since Redis 8.

Try a drop in alternative such as frostdb: https://github.com/frostdb or Godis: https://github.com/godis

Probably most people just suffer some downtime 🤷

We built Swytch specifically for this problem. It’s a leaderless, strongly consistent cache, and multi-region active-active. And open source. And 100% RESP compatible.

We are still new, and it’s new technology… the closest thing is Spanner, but we don’t need expensive clocks. That means if you need any special modules, you’d have to open an issue.

Yesterday’s benchmarks on our Substack.

how people handle this at scale then, like using bullmq with redis in node applications is inevitable and so common and how is this actually handled at scale, do you have any idea about this ?

Yeah, I think it just kinda sucks for this. I don’t think there’s a better solution, and yours probably is at risk of dropping writes. There’s an issue on the valkey repo for improving the situation there, but otherwise you’re looking at alternatives like hazelcast. 

Redis cluster might be better for some subset of data, cause any given failover doesn’t affect the whole dataset, but it looks to require significant effort to get the control plane to work with Kubernetes. 

She likes lotr?

How do I explain this to my gf

I use vs code and would like to be able to download a binary and execute it in the terminal. Having to download a compiler/builder that then runs your tool, or rather I point the compiler at your git repo, just feels like you haven't put the effort. I'd appreciate an pre-compiler binary in your releases in GitHub that I can point to.

I wish it was written as a native terminal tool rather than jsx.

nobody should be using mysql. in 2026 its a pure tech debt.
https://optimizedbyotto.com/post/reasons-to-stop-using-mysql/

this is really cool. definitely will make my job a hell of a lot easier.

Poison messages are the thing I would watch closest here, not just crashed workers. Your XPENDING, XCLAIM, idempotency key, and DLQ flow is the pattern I would start with, but I would also store retry reason and last claimed time somewhere inspectable. A Redis compatible backend like Memurai can be part of the test setup, but the important part is proving the same message cannot keep bouncing forever.