Publisher — Subscriber Pattern with Azure
We can see in most of the modern applications consists of many modules and those modules requires lot of integrations among those to make the application to complete a business flow.
Ex :
In an event management system when a new event is registered , that registration module needs to notify the Venue Handling, Speaker Management and ticketing modules.
It is very important that we keep publisher and the subscribers decoupled so we can introduce new modules (new features) to the system without changing the existing systems. Also modern systems requires high scalability we need to make sure publisher and subscriber integration happens asynchronously with out waiting.
Publisher- subscriber model is one of the most commonly used pattern to solve the above business problem.
When is comes azure there are many options for us to select as message broker, each of them seems quite similar to each other but each has its own strengths and weaknesses.
Let’s first see what the messaging/ Events services available and then let’s discuss usages of those in different contexts.
Before going in to services it is important we understand the difference between an event and a message.
Event :
Event is a light weight notification of a state change of a given component.
Publisher has no contract with the subscriber on how subscriber handles the event.
Message:
Raw data produces by the publisher to be consumed by a subscriber.
Publisher has a contract on how subscriber would handle it.
For more details read here
Azure Services to implement Publisher- subscriber patter
This has been a challenging decision on when to use what service. Let’s discuss the unique features of these two services then we can choose the service based on our business problem. Event Grid Topics and Service Bus topics are most commonly used services to implement this pattern. Before going in to details of these service it is important we understand the difference between pull and push.
- Push
When message broker use this mechanism, subscriber has no control over message flow. If your receiving party should have enough scalability to handle the load coming in.
2. Pull
In this method receiving party has full control over message flow. But this is sometimes more expensive as receiver needs to poll the message broker all the time. But if you receiver is a low end service with less scalability them pull would be the preferable methods of receiving the messages.
- Event Grid Topic
Event Grid is an eventing backplane that enables event-driven, reactive programming. It uses a publish-subscribe model. Publishers emit events, but have no expectation about which events are handled. Subscribers decide which events they want to handle.
When we to use Event Grid Topics to implement pub/sub pattern in our system to manage the integrations among the components we have to use the event grid custom topics which we can use to publish custom events to the event grid. Event grid has following feature which enable us to implement a pub/sub pattern within our solution.
- This is a service with serverless offering so we pay for what we use.
- Cost is very low : for 1 million requests its only $0.60.
- Uses push mechanism
- Routing event to subscriber based on event type, subject or body payload. This means we can publish different types of events to same topic based on event type, subject or content in the body payload we can set routing to the subscribers.
- Comes with messaging features like dead letters and retry mechanism to guarantee the message delivery
- This supports both cloud and on-prem subscribers which enable us to manage even a hybrid solution architecture.
2. Service Bus Topic
Service Bus is intended for traditional enterprise applications. These enterprise applications require transactions, ordering, duplicate detection, and instantaneous consistency. Service Bus enables cloud-native applications to provide reliable state transition management for business processes.
Service bus has set of unique feature which intended to solve some specific business needs.
- This supports order of the delivery. if your application has a need which the messages should be processed in the same order which it was received then service bus is the right choice as event grid does not support this.
- Service bus supports both pull and push mechanisms. if your receiving end is not scalable and need to implement pull then better to go with service bus.
- Supports duplicate detections of the messages. This is especially useful when messages are sent over instable networks, and the receiver does not implement idempotency.
- Supports temporal forwarding. Service Bus has the option to store messages, and only make them visible after a certain amount of time / at a certain moment.
In solution designs we can see both services are use together. Mostly service bus is used as a messaging platform for workflow orchestration and event grid is used for managing integrations among micro services or different components of a application.
Conclusion
Considering all the features in both the services , Event Grid would be a better choice to implement publish subscriber model to manage communication among micro services based on event driven architecture, unless your application has very specific needs which is only supported by service bus messaging.
