Publish and Subscribe model

Publish/Subscribe is a communication paradigm for a large-scale system. It enables loose coupling between mutually anonymous components and supports many-to-many communication.

The core concept of the Publish/Subscribe model is very simple. A Publisher publishes information on some topic, and anyone that is interested in the information will be able to find that information at the same time, simply by subscribing to that information. Well known example of this pattern is News Feeds and end user that are interested can subscribe to the type of news feeds they like to listen. Let's review  key components in the Publish/Subscribe paradigm:

• Publisher (message sender):
  • Middleware connects the Publish/Subscribe middleware to communicate
  • Publishers produce events without any dependence on subscribers
  • Publishers advertise the events they are prepared to publish
  • The publisher announces an event without having any understanding of the potential subscriber
• Topic:
  • The topic is conceptually similar to the queue, but the topic can have a copy of a given message that is forwarded to multiple subscriptions
  • Topics and subscriptions provide a one-to-many form of communication-based on the Publish/Subscribe pattern
• Subscriber (receiver):
  • Subscribers register their interest in receiving events through a subscription that the middleware handles
  • The subscriber can subscribe and unsubscribe to events
  • The subscriber has to express interest in one or more events and only receive events related to their interest, without any knowledge of which publishers can provide that given event
• Subscription:
  • Provided once the event is received and a subscriber consumes it, the same event cannot be replaced, and new subscribers will not see the event to eliminate duplicate processing of events
  • Subscription is similar to a virtual queue that receives copies of the message that were sent to the topic; you can optionally include filter rules for a topic on a per-subscription basis, which allows you to filter messages as illustrated:

Key benefits of the Pub/Sub model are as follows:

• Decoupling (loose coupling): Space, time, synchronization decoupling:
  • Space: The publisher and subscriber don't need to know each other either by name or IP address, for instance.
  • Time: The publisher and subscriber don't need to run at the same time.
  • Synchronization: Operations can continue at both ends of the spectrum (publish and receiving).
• Highly parallel:
  • The model is highly parallel in that subscribers can process events and, at the same time, the publisher can keep publishing events.

• Scalability:
  • Due to the decoupling nature and parallel nature of the model, the Pub/Sub model is highly scalable.
  • To achieve higher velocity, events can cache and smarter routing to the subscriber can be configured to scale.
  • The key challenge with the Pub/Sub model is scaling to millions of publishers and subscribers.

In addition to the preceding, there are two key challenges with the Pub/Sub model:

• No guarantee of message delivery because of the decoupled nature of the model
• For applications that totally depend on guaranteed message delivery, the queue-based model will not fit