ELI5: What is the Publish-Subscribe Messaging Pattern?

Used in microservices architecture (a method of designing software applications that is rapidly growing in popularity), the publish-subscribe messaging pattern is a form of asynchronous communication where messages are published to a topic and received – in real-time – by consumers who subscribe to the topic.

Now what does that really mean? What are the advantages of publish-subscribe? How can you explain it to someone non-technical?

In this blog we will focus on two answers: the technical answer and the functional/business answer using a television broadcasting analogy.

What is the Publish-Subscribe Messaging Pattern?

The technical answer:

Publish-subscribe is a communication pattern that is defined by the decoupling of applications, where applications publish messages to an intermediary broker rather than communicating directly with consumers (as in point-to-point).

In this sense, publishers and consumers have no knowledge of each other; they simply produce or receive the events. The event broker (in the form of middleware software, appliance, or SaaS – deployed in any and all environments) is a product that facilitates and distributes events as they occur, pushing them to consumers which can be located in a variety of environments themselves (on-premises, public/private clouds, etc.).

The functional/business answer:

It would be highly inefficient to have to constantly ask news producers like CNN if anything new has happened in the world. Considering the amount of interested parties, it wouldn’t be feasible for news stations to have back and forth communication with each and every television set or viewer that was interested in what they had to say. By extension, it also wouldn’t make sense to expect this from expanding enterprises looking to distribute their data across multiple environments and platforms.

Publish-subscribe is a messaging pattern suited for the real-time world we live in today. Just like television broadcasting, where events and messages are communicated to any television set that has “subscribed” to the channel, publish-subscribe is about pushing information out rather than having others pull or request it.

Applications (viewers) interested in receiving particular information (news, movies, reality TV, kids programming) will subscribe to relevant topics (channels), registering interest with the intermediary broker (telecommunications network of choice).

The pattern pushes this concept a bit further, too. In the real-world analogy, consumers still have to tune-in or navigate to the channel to see the content. With publish-subscribe, there would be a notification when something of interest was happening in real-time (a live event or even the start of your favourite show) – depending on the “topics” you subscribed to. This way, you can be sure to see the content you want to see, as it’s happening. For those who still watch live TV (news, sports, etc.), that is still a very valuable concept.

The Advantages of the Publish-Subscribe Messaging Pattern

In a modern environment utilizing microservices or event-driven architecture, the publish-subscribe messaging pattern offers a variety of advantages over point-to-point and request-reply communication.

The technical answer:

In a real-time world – where data is often asynchronous, and where high performance, high availability, and producer/consumer scalability are paramount – the publish-subscribe paradigm ensures your system can handle data traffic effectively and efficiently.

In short, it eliminates the need for polling. Polling is where a client constantly checks-in with a server to see if there is any new information available. If your applications rely on real-time events, polling for new information can add delays to your processing that you may not be able to afford. Instead, an event-driven paradigm sends notifications to subscribing client applications the moment an event occurs.

Decoupling is a main advantage to the publish-subscribe messaging pattern in that it allows for applications to operate independent of each other. A lapse in connection or even adding another service won’t have the same undesired consequences because applications are not aware of each other.

In a tightly coupled paradigm, a slow consumer could jam up the whole process. Downstream services can’t react, and the producer can’t send new messages elsewhere, until the recipient consumes the message/event. With publish-subscribe, the producers don’t know or care how many consumers there are, or how active they are.

Even in the case of a slow consumer, guaranteed messaging can be used to buffer the data delivery so as not to overwhelm it. The consuming application that is having trouble keeping up can consume and acknowledge without worrying about message rates, and the producer is able to publish as quickly as possible and does not need to account for potentially slow receiving applications.

The functional/business answer:

Imagine being a viewer and having to wait for all other television sets to receive the news before it could be delivered to you? With point-to-point communication, this is what’s happening. It would be extremely frustrating if news stations cared about the status of everyone’s television set. Is it on? Are they busy watching something else? Are they having glitches in their service? Are they in a remote location? – no one would ever get the information they needed and others would miss out completely once the news was over.

With the publish-subscribe messaging pattern, applications can produce and consume events without having to know anything about each other, just as one household watching CNN doesn’t have to know about (or rely on) their neighbours’ viewing habits or connection status. You simply subscribe to a certain set or type of channels, and if you want to see something specific, you just tune in when you want to.

Other people adding or removing services also doesn’t affect your ability to consume the shows you want. In this way, scaling isn’t an issue because each consumer is independent instead of interconnected. Publish-subscribe offers flexibility and scalability in a way that point-to-point communication cannot.

In conclusion

As consumers ourselves, we understand the need for instant gratification and immediate delivery (if it isn’t one-day delivery, do we even want to buy it?), so why would it make sense to submit your software applications to anything different? Especially if real-time reactions and great customer experiences are critical for your business.

Unlike other communication patterns, publish-subscribe ensures message delivery occurs as soon as the message is available to the intermediate event broker. Publishing applications don’t have to wait for a response from a receiving application, nor do subscribing applications have to wait for messages to be delivered to other subscribers before receiving a message.

An event broker supports the development of modern cloud-native and event-driven apps and microservices, making it a foundational element of event-driven architecture. Utilizing an inherently distributed messaging pattern like publish-subscribe for your microservices is ideal if you’re looking to:

• Increase flexibility
• Speed-up response time
• Decouple applications
• Improve availability
• Improve scalability

Event-driven communications is the best way to realize the full potential of microservices architecture. To learn more about how event broker technology can improve your management and governance, increase your capacity and performance, and enhance your messaging capabilities – check out the Solace PubSub+ Event Broker.