[topspin]

I am thinking of using Redis as a lightweight queuing mechanism. An event source will MULTI a small amount of metadata as a hash and append a list. Event sinks will BLPOP the list and retrieve and delete the metadata key. One requirement is the events survive power loss.

Is there anything inherently wrong with this? Gotchas? A mockup I've done works great so far.

[renonce]

In case the event sink crashes or the connection to Redis is lost, you could lose events. Redis Streams are better designed for use cases where more reliable delivery is needed and have a ton more features, though it comes with more complexity.

[topspin]

I hadn't looked at streams yet. Thanks.

This page from AWS about Redis streams goes exactly to my use case: Redis Streams and Message Queues: https://aws.amazon.com/redis/Redis_Streams_MQ/

[zo1]

RabbitMQ. It's so cheap and easy to startup a super performant queuing broker with docker these days. And the libraries are all there, async ready and with established patterns. Closest to zero code you can get for this. You'll likely end up reimplementing all those patterns and support around them using redis.

If you want something quick and easy and dirty, go with Redis. But switch to Rabbit when you start having to write a lot of handling and other code.

[CSDude]

There used to be disque by antirez, which died. https://github.com/antirez/disque

[topspin]

See my other reply where the disque author talks about exactly that.