Strongly, strongly, disagree that Redis works well as a message bus.

Lots of reasons why but here is just one because I'm short on time: all of these (four) ways of doing a message bus with Redis offer either a work queue mode or publish/subscribe - but not both (perhaps excepting streams which I've forgotten some of the details of). I have yet to see many real world messaging scenarios where you don't end up using both.

A "proper" message bus needs to have topics, exchanges and queues - like Rabbit. 50% of that functionality is usually not 50% of the value but 10% or less (especially when you consider all the other things about Redis you need to think about - like how eviction is configured).

This is a bit typical of Redis: for any X, you can normally do X in Redis, but is it really a good idea to do X in Redis? IMO, usually no.

There's a wide field of messaging from distributed logs to queuing systems to event sourcing to complex service buses. Kafka, Pulsar, NATS, RabbitMQ, Tibco, NServiceBus, ActiveMQ, Solace, AMPS, and dozens more. What's "proper" depends on your needs.

Redis Streams actually does exactly what you describe and is basically a single-node fast Kafka replacement with multiple independent consumer groups, per-message acknowledgements, and queue semantics. We use it successfully in many high-load scenarios.

Name of the hash is a topic. Keys are nanosecond timestamps, values are the packets. You put in the data, you send a pub notify to the listener, listener goes and drains the queue. It acts as a direct exchange queue, recovers fine from a restart and it works wonderfully. For fanout, you can simply use pub sub. For topical, you can keep a list of direct exchange queue hashes. I haven't needed it.

Redis Streams is built-in and does all that for you. https://redis.io/topics/streams-intro

You're probably right. I did this before streams were a thing.