Event Driven Architecture, The Hard Parts : Should it be Event or a Message ??

If you happen to use Event Driven Architecture in your product, then I am sure you would have come across many situations where it was not a straightforward decision for you to decide — should I be using Event in this case or should I be using Message? In-fact, you might have also come across this thought of — let me always use Events :)

Well, things are not always black and white. Every decision we make in the software world is influenced by the context we are in. In this blog, we will look at some of the use cases and see if an Event would make sense or a Message to implement the same.

If you want to know more about the difference between an Event and a Message, please check my previous blog here.

Let’s do a deep dive by taking some of the use cases —

Social Networking Site Use case —

Let us take the example of a Social Networking Site which allows users to create a feed post, comment on a feed post, follow/unfollow a user, etc. And an email notification is sent to the author —

1. When a feed post is successfully moderated by the system
2. Someone comments on the posts created by the author
3. Someone follows/unfollows another user
4. And many more

To implement the notification use case, the Team has realized this domain problem using Microservices Architecture by creating multiple microservices like — Feed Service, Comments service, Like service, Follow service, etc. And a cross cutting horizontal Notification service to send email.

Event Driven Approach for sending Notification

The respective Domain services publish business events for the actions performed in their domain and these events can be consumed by other consumer services to react to the events. One of the consumers being Notification service.

The pros of this approach —

1. Highly scalable.
2. No additional effort needed by the domain services to send email notification. The business events being published are consumed for sending emails.

And the Cons —

1. Since the solution leverages Fire and Forget approach, domain services have assumed that if they publish events to the Event Broker, Notification service will pick those events and will send email to the users wherever needed. The domain services are not really keeping a track of it.
2. Notification service needs to understand the schema of each event and derive the relevant information needed to send the email. With more and more use cases added, continuous work for Notification Service Team to understand those events for sending emails.
3. Some of the use cases would be tough to implement with this. Example — A new business requirement comes, which says if a feed post is liked by 10 users, the author is to be notified by the email. Like/Unlike service simply asks the Notification teams — since I am already publishing all the Like/Unlike events, you can maintain a state at your end and take necessary actions. Well, technically this looks doable. But it is actually a business domain leakage into Notification service. The responsibility of a notification service is to
4. Moreover, if there is a sudden spike on the business events and emails are to be sent for each event, the Notification service may not be able to scale well. Example — Assume, this architecture is leveraging Kafka. And Feed Post service is publishing events on its own Kafka Topic FeedPostsTopic which has 5 partitions. Which means, the maximum consumer instances the Notification service can have is 5 (internals of Kafka). Now if FeedPostTopic has increased the partitions from 5 to 10 for some reason, the Consumer service being unaware of this change continues to operate with 5 consumers.

Given this feedback, the team flips the approach and comes up with the following solution —

Message Based Approach for sending Notification

All Domain services send messages to the Notification service in a point to point fashion.

The Pros of this solution —

1. Domain services can follow the message schema published by Notification service for sending email. Once stabilized the implementation, not much work for the Notification team, other than the operational aspects.
2. Because the Message Queue is owned by Notification service, it can use Queue depth metric to scale the service instances to process the events fast.
3. Since domain services are responsible of their own data, they can easily handle the use case we discussed above — If a feed post is liked by 10 users, the author is to be notified by the email. No impact on Notification service.
4. Domain service has an assurance that the email would eventually be sent as the Queue is owned by Notification service.
5. Domain services now have the option to track the email sent response by requesting an acknowledgement on another queue. And if they don’t receive the acknowledgement in a pre-defined time, they can retry the email delivery request by sending another message in the Notification Service queue.

And the Cons —

1. Apart from publishing the Domain events, there is an additional effort on the domain services side to also send a point to point message to the Notification service.

Let me add a new requirement here —

Every user has the option to configure if they want to receive email notification for individual use cases or not. Example — I as a user want to receive email notification when someone comments on my feed post but I don’t want any email when someone follows/unfollows me.

With this requirement in mind, what do you think which approach is better — Message or Event and why? Do respond to this by adding a comment to the story.

Food Order Use case —

A simple use case, where users can Order food from a Restaurant and pay online.

Event Driven Approach to make Payment in Workflow

In this case, our focus is on the interaction between Order Manager service and Payment service. The team has leveraged an event mechanism to publish an event when a user places an order from Web or Mobile interface. The event is to be consumed by Payment service to initiate the payment for the order.

The same event is also supposed to be consumed by the Analytics service. And you may not want to expose payment related details of the user to the Analytics service.

If two services have to be communicated different data payload, then messages are the way to go.

So in this case, the Order Manager service should use the message approach to communicate to the Payment service before it publishes the OrderCreated event.

Message Based Approach to make Payment in Workflow

The workflow depicted above is just to explain the concept and should not be taken as a real workflow :)

Use case where sequence of execution is important —

Another situation where you want to use Messages is — if you want to control the sequence of execution in a Workflow. For more details on this type of use case, take a look at this blog —

Event Driven Architecture, The Hard Parts : Events Vs Messages

I hope this blog has given you some clarity on when to use Messages and Events and the pros and cons of each approach.

Hope you enjoyed reading this blog. Do share this blog on social media if this has helped you in any way.

Happy Blogging…Cheers!!!

#EventDrivenArchitecture #Events #Messages #Microservices