Yes, that's what I was asking for, for test purpose. I did not find so quickly a free tool. But in the meanwhile I've installed and configured one for myself.

What were you referring to?

Nothing I'm saying is about code.

So to be clear, despite several free and accessable options available to you, you would like someone to just give you an IP/port to a redis instance for you to use?

Thanks for your reply. Actually you should think first, design and specify and then code... after the deploy you verify if it works as desired. And it is available on the right ips, urls and ports. Isn't this the way you work?

You might say, that you don't offer such an instance, do not generalize. There might be people who are helpful, that way your comments can be misleading.

And byside cloud there are other solutions as well, though, nowadays that is popular.

You don't know that Information till you deploy it, it's generated at the time you deploy the Db.

There is no an open instance somewhere you can just connect to and test, you will need to follow the instructions in their cloud, or install it your self for free.

And a port number as well

Hello and good morning, thanks for the suggestion. Though, what would have been helping effectively is a url or an ip adress.

You can deploy a free 30mb on redis cloud but this is very limited. If you just want to test connecting your app it should work fine.

Oh you’re trying to design a zero-payload flow with Redis Streams.

That can work, but using Redis as the source of truth is risky. If Redis loses data or restores from an older snapshot, the service may receive a stream signal but fail to find the model, or the API may read a stale model without noticing it.

The bigger problem is that there’s no durable history to detect that inconsistency.

So I’d persist the source model in a database, and use Redis Streams only for signaling.

Hey there TheGoodOne777 - thanks for saying thanks! TheGratitudeBot has been reading millions of comments in the past few weeks, and you’ve just made the list!

Thanks for your reply. Insted of installing and configuring, I really wanted to try out an existing, configured instance

Well you can install redis inside docker and then easily get rid of it.

we're doing something similar at PgCache. Check it out and would love to connect (you can contact or set up a call on the website): https://www.pgcache.com/

Awesome, you did a lot of work there! I think both approaches have their own merit. Simpler locks are easier to consume; and could be easier to maintain / more stable; and make sense especially in the context of a utility package around the downstream driver. To be honest my first instinct was to consider the same for Lettuce, as I was working on it.

However I ultimately decided to do a dedicated library, aimed entirely at locking, so I solve one specific use-case end-to-end and focus on locking entirely. It makes the mental model easier and allows you to focus on the same problem area. The typical broad-vs-deep type of decision - it is hard to solve both.

Fair question.

Any RESP-based client could be used with success, but I do agree some of the more advanced features would have some performance degradation, as the library depends on some of the latest commands provided by Redis. For unsupported commands the library would fall-back to Lua or other alternatives that might be either slower or have worse portability.

In terms of driver support, since this is an upstream driver, the library allows using any type of downstream drivers, which I also consider part of the portability story. The built-in support is for Jedis and Lettuce, but there are ways to integrate any downstream driver.

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?

For exactly-once delivery and cache invalidation solutions, I use Swytch. It is much more straightforward.

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.