Hello folks!
I've been studying event-driven architecture for about a month now, and I wanted to write about it so I can better fix the knowledge in my head.
Quick disclaimer
I am using Apache Kafka in my studies because that is what we use in the company I work with, but I am sure that most concepts I've learned can be applied to other tools.
Also, as I have mentioned, I am a beginner in this subject, I could be very wrong about some things, and if I am, I would love some feedback about it.
What
Event-driven architecture is a way of thinking about software architecture where things (events) happen in the business and our system reacts to it.
This architecture has three main components:
- event emitters (aka producers, aka publishers) that are responsible for capturing and sending events to the system.
- event listeners (aka consumers, aka subscribers) that react to the events applying business logic.
- brokers which are the glue that receives the events from the emitters and sends them to the listeners.
As far as I know, event-driven architecture is always based on microservices, meaning, each of these components is a separate service.
Why
Event-driven architecture solves the problem of having a huge volume of data that needs to be asynchronously processed while supporting future change in the system.
Most of the examples I've found talk about payment processing, where you can have N orders being processed by different services so the information can come out of order and have multiple outcomes that need to be handled in a unique way.
Maybe you want to have systems that both notify the user about a failed payment and send information to a business dashboard;
You achieve this with both monolithic and regular microservices architectures, however, this will lead to more dependency between your modules or services.
But if you have an event-driven architecture you could easily just write a new service that handles this exact same data (let's say you also need a client dashboard now) without interfering with how the other two systems work.
How
I will grossly over-simplify the process of implementing this architecture but I intend to make other posts on the subject explaining it better.
1 - Pick a message software.
There is plenty of message queue software out there, do some research on their pros and cons.
Pick the one that makes more sense to your needs.
2 - Map your business needs and business events add them to your architecture.
Like in the example in the previous section, you have both events and business needs, add them to your design. so it should look like this >
Item purchase > ? > Notifiying customer
You will need to do something like this process for each of your business needs. In this case, the business need is to have customers notified of their successful purchases.
3 - Design a path in which the data is transformed from events to fulfilling your needs.
Now is time to design the services that you will need to make this event into a notification.
In this case, we should need only two more steps, one to validate the order and one to notify the customer.
So our project would look something like this >
Item purchase event
Order validation service acts upon this event, generating another event for validated order (or invalid).
Notifying services acts upon this event and send the notification to the user.
4 - Set communication interfaces for the services.
For each of these events, we need a (preferably documented) data structure that represents what happened, so other services can later act upon the events.
5 - Done, start coding.
The architecture phase is done, you can move to develop the system.
Once you finished doing all of this work, you will most likely have a lot of new ideas on how to improve your architecture, and that's why you should always keep in mind that can and will occur, your systems and data structures should be easy to alter.
Top comments (0)