Topic-based Publisher Subscriber Design Pattern

When it comes to design, I have a pretty simple philosophy: set up something that is generic and reusable. But design patterns sound way easier than they actually are. It is like setting up the electricity wiring for your newly built house. You know that you need approximately 200 Amps of electricity, but actually setting up the wiring is altogether a different ball game. Like I said, deep diving in the sea of design patterns was not an easy task. Thankfully, I came across the Publisher Subscriber Design pattern, which is generic, easy to use and dynamic, meaning I can dynamically add anything with just a few clicks!

Publisher Subscriber Design Pattern: A Closer Look…

As far as the architecture is concerned, a Publisher Subscriber Design Pattern will generate messages for another system to consume. This chaining will go on for n levels.

1. Publisher - Publishers post messages to any message broker or queue; for topic based pub-sub model messages, belonging to a specified topic to which Subscribers can subscribe to.
2. Subscriber - Subscribers can subscribe for the messages published by the publisher system through topic based subscription via a message broker or a queue.
3. Topic Subscription - The topic subscription will hold the subscription specific details. Since the Publisher would not know its subscribers, the messages would be routed to the subscriber based on the topic subscriptions.

In short, the Publisher system is going to publish to the Message Broker/Queue where the topic subscription would already be set in. So this architecture signifies the many-to-many relationship between the end systems.

Schema Structure & Analyzed Keynotes

Before starting to put anything architecturally, I needed to think of a generic data model that would suffice for any kind of system. A single system ideally would work as a Publisher as well as a Subscriber for others.

The data model shown below leverages Event Notification Service to capture any messages that need to be published/subscribed in the form of an event.

1. System Table - This table would hold the Publisher and the Subscriber information. Each system should be associated with one unique key constraint so that this would be globally unique.
2. Topic Table - This table would hold the list of Subscribing & Publishing topics. Based on these topics, the system would either consume the message it has subscribed to or publish the message
3. Event Table - This table will be associated with the Topic & the System. This object is the entry point for data flow within the system or externally. Any operations that need to be performed within the system or outside the system will be flown through the Event table.

Generalization of Structure

1. Whenever any event records get created across any topic, the system would generate an automated process to perform the respective operation.
2. The post logic would be run either for further raising any events acting as new Publisher or respond to its respective publisher system.

Advantages of Publisher Subscriber Design Pattern

1. Scalability - It takes just a few clicks to add / remove the event subscription. Whenever you want to add/remove any system, you just need to go and update the queue table which will eventually start/stop acting as per the requirement
2. Single Point Control - Updating a single table will change the whole cycle.
3. Implementation Cost – This architecture is quite simple to implement. The structure of each system for handling the event notification structure remains the same and hence leads to considerable reduction in implementation cost.

Disadvantages of Publisher Subscriber Design Pattern

1. Failure In Message Delivery - Failure in delivering a message would cause a problem to the subscribing system in case you need the messages to be delivered in a sequence.
2. Ordering – In case custom sequencing or ordering is not implemented, the messages do not guarantee an order.

The final word…

Despite its due share of cons, I would recommend using the Publisher Subscriber design pattern, especially when you want to put a dynamic and reusable architecture and make multiple systems interact amongst each other, that too, with just a few clicks! Why don’t you give it a try and tell me how it worked out for you?




Written by Amit Shingavi,  Salesforce Developer at Eternus Solutions