Oftentimes when working on an application that needs to be easy maintainable, scalable and performant, developers will go with Publish/Subscribe messaging pattern.

The idea behind it is simple, but powerful. We have senders called publishers. Their sole role is to send or publish messages. They don’t care about who is going to receive them or if someone will receive them at all. They just shoot and forget the messages. And they do that via so-called channels. Think of them as for example TV channels. We have Sport channels, Weather Forecasting channels, Cooking channels. Every publisher could send its messages to a certain channel, and whoever is subscribed for this channel will be able to receive these messages.

Here is where the subscribers come in play*.* They can subscribe to one or more channels and start receiving the messages broadcasted in there. As we already mentioned, the messages are to be sent and forgotten, which means that if a subscriber subscribes for a certain channel, all the messages that were sent previously in that channel are not going to be available to this subscriber.

Due to the nature of this kind of architecture we can easily achieve low coupling between the different components and provides a solid foundation for building robust and easy-to-maintain applications. For example, imagine a situation where we need to replace or improve the publishing part of our system, say add more publishers, more channels or so on. Since the two parts are isolated, meaning publishers don’t care about subscribers and vice versa, we could easily do that without worrying whether we are breaking some other part of the system. We just add the new publishers and then later, when a subscriber comes to the relevant channels, it just starts using them.


The initial idea behind Redis was to serve as in-memory cache solution, as an alternative of its ancestor Memcached. But nowadays it became many-in-one solution - it provides in-memory data structure store, key-value database, message brokering and so on. This makes it perfect candidate when building an application that needs really fast caching solution as well as some of the other features mentioned before. Especially if the performance of the app is crucial for its normal usage.

Redis performance comparison (source: google)

Redis performance comparison (source: google)

One of the biggest advantages when using Redis is the huge community and technical resources one can find online. A lot of these resources are free, also there are online platforms that have free tier offerings. Redis includes in its arsenal a cloud solution as well. If you want to try it yourself, you may go here and register a free account or use their initial coupon offering.

Redis Enterprise Cloud Sign Up / Sign In page

Redis Enterprise Cloud Sign Up / Sign In page

Pub/Sub in Redis


What is it?

Publish/Subscribe channels in Redis is one of the features I haven’t mentioned above but it’s already included in the last versions of Redis. This is their implementation of the aforementioned messaging pattern (Pub/Sub) where we have publishers and subscribers which exchange messages via channels. Let’s go briefly through it below and then we will see it in practice, in a small demo app I have prepared for you.