Understanding Event-Driven Architecture: A Simple Guide
H
Backend Engineer with expertise in AWS Serverless Technologies.
Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
Search for a command to run...
Backend Engineer with expertise in AWS Serverless Technologies.
No comments yet. Be the first to comment.
Event-driven architecture is one of the ways systems interact with each other. It closely resembles real life, where everything is an event. My waking up in the morning is an event, and my starting to write this blog post is an event. There are many blog posts on this topic, but I believe I can explain it better with the help of an example.
Suppose we have two microservices: User Service, responsible for user-facing APIs such as login, signup, etc., and Messaging Service, responsible for sending emails, push notifications, etc. When a user signs up, we want to send an email stating that the user has signed up successfully. The conventional flow in the microservices world would be as follows: the client hits the User Service signup endpoint, and User Service performs the business logic of checking for existing email, storing data in the database, etc., and makes a REST API call to the Messaging Service with the input of userID, email, etc. The User Service then waits for the Messaging Service to return a successful response before returning a successful response itself to the frontend client.
There are several disadvantages to the following approach:
Tight coupling between both services. If there is a change of endpoint in the messaging service, it needs to be changed in the user service as well, and both of them need to be deployed together. If the messaging service goes down for some reason, the end user will not be able to sign up even though sending an email is a secondary business operation. This coupling makes us question why these were separated into different microservices in the first place.
The user service needs knowledge of the messaging service's existence and must be configured accordingly.
With more services entering the picture, you can imagine the complexity of just a simple user flow.
Answer this question: if a user receives an email confirming their successful sign-up a couple of seconds later than usual, would it be a dealbreaker?
In most cases, the answer is no. Believe it or not, most processes can be done asynchronously. I believe that anything that can be done asynchronously, be it work communication or software communication, should be done asynchronously. This is because asynchronicity brings the advantage of loose coupling.
Now, if we introduce the concept of events into the above flow, how would it look?
1. User service receives a signup request from the user.
2. User service performs all the validation and business logic, then saves the user to the database.
3. User service emits an event called "UserCreated."
4. Messaging service listens to this event, and its payload contains the information about which user to send the email to.
Can you notice the difference in the above flow? All the disadvantages we listed earlier are resolved, and these microservices are now loosely coupled.
In conclusion, event-driven architecture can provide significant value and can be adapted for tasks that are asynchronous in nature. I have intentionally not delved into specific technologies through which we can achieve this and hope to cover them in future blog posts.
I hope you enjoyed what I wanted to share. This is my first time blogging, and it's a bit intimidating, so I would really appreciate your feedback and support :)
