Event driven architecture

event driven architecture is a pattern of architecture for applications following the tips of production, detection, consumption and reaction to events. it is possible to describe an event as a change of state. for example, if a device is shutdown and somebody opens it, the state of the device changes from shutdown to opened. the service to open the device 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.

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 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.