Event-driven architecture (EDA) is a pattern of architecture for applications following the tips of production, detection, consumption of, and reaction to events.
It is possible to describe an event as a change of state. For example, if a door is closed and somebody opens it, the state of the door changes from closed to opened. The service to open the door has to make this change like an event, and that event can be known by the rest of the services.
An event notification is a message that was produced, published, detected, or consumed asynchronously and it is the status changed by the event. It is important to understand that an event does not move around the application, it just happens. The term event is a little controversial because it usually means the message event notification instead of the event, so it is important to know the difference between the event and the event notification.
This pattern is commonly used in applications based on components or microservices because they can be applied by the design and implementation of applications. An application driven by events has event creators and event consumers or sink (they have to execute the action as soon as the event is available).
An event creator is the producer of the event; it only knows that the event has occurred, nothing else. Then we have the event consumers, which are the entities responsible of knowing that the event was fired. The consumers are involved in processing or changing the event.
The event consumers are subscribed to some kind of middleware event manager which, as soon as it receives notification of an event from a creator event, forwards the event to the registered consumers to be taken by them.
Developing applications as microservices around an architecture such as EDA allows these applications to be constructed in a way that facilitates more responsiveness because the EDA applications are, by design, ready to be in unpredictable and asynchronous environments.
The advantages of using EDA are as follows:
- Uncoupling systems: The creator service does not need to know the rest of the services, and the rest of the services do not know the creator. So, it allows it to uncouple the system.
- Interaction publish/subscribe: EDA allows many-to-many interactions, where the services publish information about some event and the services can get that information and do what is necessary with the event. So, it enables many creator events and consumer events to exchange status and respond to information in real time.
- Asynchronous: EDA allows asynchronous interactions between the services, so they do not need to wait for an immediate response and it is not mandatory to have a connection working while they are waiting for the response.
Microservices are commonly used in large projects to divide their services into smaller ones. So, it is really important to have good and organized communication between them. Event-driven architecture can be used to solve the common issues of communication between microservices.
In a project based on microservices, usually every microservice communicates with each other using HTTP requests. This has some problems that we will now explain.
In our Finding secrets project, there is a function to create events for the users. When a new event is created, the event name and the images attached in the event form need to be sent to a service to create a video from the data received. Once the video is generated, the event will be updated and sent to the users by e-mail.
If we make HTTP requests for each service, the problem is that all the services need to know about the others. For example, the service to generate the video needs to know how to update the event once the video is generated; in other words, the service has to contain code to do this update.
Also, this becomes more and more difficult once we add many services because it will need more communication between them. It will have more failures and the main problem is that if a microservice is down, the video will not be generated. So, using HTTP requests is not going to scale pretty well and we should use a different strategy to communicate microservices in projects like this one.
What if we do the things differently? In other words, the service to generate the video will not update the event directly and the event will not ask the video service to generate the video. So, how can we make the microservices communicate? The answer is with event-driven architecture.
To do this, we need the following things:
- A queue of events for each microservice
- All the microservices have to send the event to a centralized BUS (we can use AWS to do this)
- Every queue of microservices has to be subscribed to the centralized BUS
- Every microservice has a background worker listening to the queue of events and it will execute the necessary action when receiving an event
In the following figure, you can see the different services involved and the process flow, indicated with arrows. The following figure shows the event-driven workflow:
When we create a new event on the EVENTS SERVICE API (1), the event goes to the centralized BUS (2) and the corresponding worker gets the event from the centralized BUS (3); the rest of them just ignore the event. The event is placed in the video generator service queue and it waits to be executed by the service (4).
Once the video has been generated by a service worker, the service launches a new event to the centralized BUS (5). However, it will be taken by a different worker this time (6) and the res of workers will ignore this event as earlier. The worker to update the event and the worker to send the e-mail will put the event into their queues and it will be executed (7) doing the corresponding action for each service and they will send a new event into the centralized BUS if it is necessary.
This is a loop of events that improves the HTTP requests method for the communication between services. The advantages of using event-driven architecture are as mentioned:
- If there are any errors or exceptions on a service, the event does not get lost, it stays in the queue and it will be executed later. For example, if the service to send e-mails is down, the event to send the e-mail will be kept in the queue waiting for the service to go up again.
- The services do not need to know how to update other services. It means that the logic of the service can be isolated in each service.
- It is possible to add more microservices without impact.
- It will scale better.