What is Event-Driven Architecture (EDA) ?
It is a scalable system designed to handle real-time processing of user activities in a distributed environment. It is a software design pattern that allows the system to decouple the components by using events which help to improve scalability, modularity, and responsiveness of the system.
Architectural Style:
An event-driven architecture uses a publish-subscribe model and an event streaming model.
The system communicates with each other asynchronously to events through an event broker where applications do not need to know where they are publishing and consuming the information. Events represent a change in the state or user actions (e.g., an order being placed, user signed up).
There are 3 main components:
Event Producer:
It is an application, service or any component where the data is generated, and an event is published. The producer doesn’t know who will subscribe to this event and how the data will be processed. It can handle high volumes of events without any blocker from consumers.
Event Broker:
It is a middleware between producers and consumers. The key role of the event broker is to receive events from producers, store them, and route events to consumers. This communication is asynchronous. The routing is based on topics, queues filters.
Event brokers support multiple delivery models like publish-subscribe, point-to-point etc. It makes sure that the events are not lost through various techniques like retries, message persistence, dead-letter queues. It can also handle high volumes of events and can scale horizontally. Some of the examples are Apache Kafka, RabbitMQ, AWS EventBridge etc.
Event Consumer:
It is a component, application or service that subscribes to events published by event producers through event brokers. It processes the event asynchronously as soon as it receives. Each consumer handles specific types of events and will not know who publishes that. Multiple instances of consumers can consume events parallelly.
Communication Models:
Publish-Subscribe model:
In this model, even producer/publisher publishes events. It will not know who will consume those. Event subscribers/consumers look for specific events and subscribe to those events as soon as those are available. Producers and consumers work independently because of decoupled structure.
Event Streaming model:
In this model, event data is continuously generated and processed in real time. Events act as a stream of records that are processed, stored and analyzed as soon as they are created. Applications which need real-time analysis and monitoring can make use of this model.
When to use Event-Driven Architecture (EDA)?
Event-driven architecture is a great choice when your application needs to respond to user actions instantly and handle a high volume of events without slowing down. Each component can send and listen to events instead of having all parts of the application directly talk to each other. This decoupling of services makes it easier to update or add any new features later without affecting the rest of the system. This system helps your application to be reliable and flexible, even if traffic spikes or something goes down temporarily.
Using events makes your application more scalable, reliable, increases responsiveness, and simpler to grow over time. Overall, if you need a system that reacts in real time, handles high volume of traffic gracefully, and allows you to build and change services without breaking everything else, event-driven architecture is a great choice.
Use Case:
Let’s take an example of an online food delivery application like UberEats in which customers, restaurants, and food delivery people(drivers) need to get real time updates at the same time. Event-Driven architecture design pattern works perfectly in this case. It will allow all the different components in this system to work independently but still will stay in sync.
Here are the main components:
Order Service:
Customer places an order using the application. The order service publishes an event ‘OrderPlaced’. It will include information about customer, payment, order etc.
Restaurant Service:
Restaurant service is responsible for taking orders, send it to restaurant, etc. It listens to ‘OrderPlaced’ event. As soon as the Restaurant Service receives the event, it notifies the restaurant about the order to prepare and updates the restaurant dashboard for tracking in real time. Once order is ready, it publishes ‘OrderReady’ event.
Payment Service:
Payment service also looks for ‘OrderPlaced’ event. Once it receives, the service will process the payment and publishes a new event ‘PaymentSuccessful’.
Delivery Service:
This service listens to ‘PaymentSuccessful’ event. it tracks down all the available drivers, sends them delivery request and publishes ‘DriverAssigned’ event.
Once the restaurant service publishes ‘OrderReady’ event, delivery service listens to this event and publishes a new event ‘OrderOutForDelivery’.
Notification Service:
This service listens to all the events ‘OrderPlaced’, ‘PaymentSuccessful’, ‘DriverAssigned’, ‘OrderReady’, ‘OrderOutForDelivery’ and sends real-time updates to the customer about the order.
Tracking Service:
This service is used for real-time tracking. It tracks down all the events to send updates to notification service.
Challenges:
Debugging and Monitoring:
In Event-Driven architecture, different components in system communicates to each other through events. Even though it is asynchronous, it is difficult to trace the data flow which makes the testing complex.
Consistency:
Sometimes, events might comes out of order which can cause consistency issues if these are not handled properly.
Duplication:
Because of network issues or retries, it is possible to receive same event multiple times. If the same event received more than once, the application must be designed to handle duplicate events gracefully.
Operation Overhead:
There is always operational overhead as you need to set up and maintain tools like brokers (e.g., Apache Kafka, RabbitMQ, AWS EventBridge) to keep track of how the data moves. If the system is not scaled properly, it may cause performance degradation and can increase operational cost.
Error Handling:
Since Event-driven architecture mainly uses asynchronous communication, a challenge with it is error handling. Thus, if something goes wrong while processing an event, you need a mechanism to retry or fix it without affecting other services.
Security and Access:
These events can have sensitive data like payment, PII etc. and can be consumed by services which are not authorized use those.
Event Loss:
Because of broken failure, network issues, or incorrect configuration, it is possible that the events can be lost.
Top comments (0)