The case for publish/subscribe in your software architecture considerations

By Adrian Matei

If you are developing a core platform in an enterprise you might experience the following pains, when core elements
need to synchronized with consuming clients of the platform.

Pains

  1. You might use a push mechanism to notify clients about an core element update (e.g. user or organisation data update).
    But what happens when a new client ist added? Well your core platform needs to be aware of it. This might imply code or configuration changes,
    new deployments etc. – ** it does not scale **
  2. If a client of the platform is not online the time the update notification is pushed, it will miss the update, which might lead to data inconsistency.

Pub/Subscribe to the rescue

Both issues are elegantly solved if you use a publish/subscribe mechanism. Your core platform, the publisher, will publish the update event to a message
broker, that will be consumed by one or several clients, subscribers. See the diagram below for the 1000 words, worth of explanation:

Model architecture for a publish/subscribe scenario in enterprise

Well, a few words won’t hurt anyone: your core platform might get relevant notification events from business or private clients.
now instead of pushing the notification to the consuming clients it publishes it to a topic (might be a cloud service), where is persisted
for a configured duration or consumed by all subscribers.

The simplest scenario is to use a broadcast pattern for the topic where every subscription gets a copy of each message sent to the topic. Other topologies
could be set up for more advanced scenarios via message filtering and routing. This usually involves additional topics or queues. Most potent brokers offer
such abilities.

Benefits

The benefits are the solving of the previously mentioned points:

  • decoupling: the publisher is not aware anymore of consuming clients
  • asynchronous consumption (offline support): subscribers might consume the messages at a later time

This is no silver bullet for all your architecture needs, you might need tightly coupled systems to guarantee message delivery for example.
Just don’t forget about it, when you are designing your next (enterprise) project.

References:

  • https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

The case for publish/subscribe in your software architecture considerations was originally published by Codingpedia Association at CodingpediaOrg on July 02, 2018.

Source:: codingpedia.org