Reliable Delivery Pub/Sub Message Queues with Redis | Remember to Breathe

Reliable Delivery Pub/Sub Message Queues with Redis | Remember to Breathe

Why not use Redis Pub/Sub?

I already see you coming and asking why not using the Pub/Sub semantics supported out-of-the-box by Redis? The reason was two fold:

1. What Redis offers with Pub/Sub is a listener model, where each subscriber receives each messages when it is listening, but won't receive them when not connected. 
2. In a clustered environment where you have multiple instances of your consumer component running at the same time, each instance would receive each message produced on the channel. We wanted to make sure any given message got consumed once per logical consumer, even when multiple instances of this component are running. 

Hence the name of this post "Reliable Delivery", because we wanted to make sure every logical consumer eventually receives all messages produced on a queue once and only once, even when not connected – due to, for example, a deployment, a restart or a component failure/crash.

Read full article from Reliable Delivery Pub/Sub Message Queues with Redis | Remember to Breathe