Event Driven Architecture

8 min readJan 10, 2023

If you’re tired of dealing with the complexity and inflexibility of traditional request-response architectures, it might be time to consider event-driven architecture. In this post, we’ll explore what it is and how it can benefit your system.

Event driven architecture make it easy to handle time taking processes, complex functionalities, long wait time for users to process the requests.

From social media platforms to payment processing systems, event-driven architecture is powering some of the most successful applications out there.

What is Event Driven Architecture?

you might be familiar with traditional request-response architecture(A client, typically a web browser, sends a request for a resource to a server, and the server sends back a response corresponding to the resource), in which components communicate with each other by making explicit requests and receiving responses. Components are loosely coupled in this architecture.

In an event-driven system, components communicate with each other by producing and consuming events.This allows for more flexible and scalable systems, as components do not have to wait for explicit requests or responses.

One example of event-driven architecture is the payment processing system used by online merchants. When a customer makes a purchase, an event is generated and sent to the payment processing system. The payment processing system processes the payment and sends a confirmation event back to the merchant system, which updates the order status

Let’s try to understand it in a more simple manner with an example.

Let say, you have a system that allows you to upload videos to their platform. The system needs to handle the following tasks:

Accept video upload from the client
Inspecting the video for violations.
Transcoding the video.(converting video to other formats like MPEG, HLS etc, which provides the best stream experience based on your device and network bandwidth.)
Generating a thumbnail.
Encoding audio for the video.
Add watermarks if any.
Add meta data for that video to the database.
Uploading the video to cloud or to cdn.
and many more.

In a traditional request-response architecture, these tasks might be implemented as follows:

User uploads a video on the platform.
The platform sends a request to the video processing system to process the video.
The video processing system first pass the video into inspection checklist and that will validate if video is violating any rights or so.
Then the video will be passed through the transcoding service in which video will be converted to different formats and sizes.
The video will be used to create the thumbnail.
Then we need to pass the video through audio encoding service for encoding the audio.
Once audio encoding is done, we need to add an image overlay on top of the video.
Then we need to upload the video to cloud for better accessibility for user. ideally CDN.
Once this all is done, we need to update the database for the metadata and image related content.
Then we’ll be able to return the response to the user saying that video upload is success or so.

In this scenario, the website is tightly coupled to the video processing system, and the video processing system is tightly coupled to the other services that are responsible for handling operations like encoding, compression, watermarking etc. If any of these components fail, the entire system may be affected. Additionally, if the system experiences a high volume of video uploads, the video processing system may become a bottleneck.

This type of architecture is commonly used in many systems, but it can be less flexible and scalable than other architectures, such as event-driven architecture.

In an event-driven architecture, the components communicate with each other asynchronously through events, rather than through explicit requests and responses.

Now, let’s consider how this scenario could be implemented using event-driven architecture:

User uploads a video on the platform.
The platform generate a “video upload” event and send it to the event-driven system.
The event-driven system routes the event to the video inspection component, which will check if video is not violating any rights. Once video inspection is done, it will generate a “video processing” event.
The event driven system routes the “video processing” to the transcoding, thumbnail , audio encoding, compression, watermark components.
As these components are loosely coupled, they can work in asynchronous manner.
Each of these components are decoupled from each other, as they communicate through events rather than direct requests or responses.
User can upload the video and carry on with their other work as they don’t have to wait for server to process all these things. These processes are being handled asynchronously.
Once all the components are done with their respective manipulation for the video, we can notify the user.

Introducing message broker, Component pull events from message Broker, Components are decoupled.

In this event-driven architecture, the website is decoupled from the video processing component, and the video processing component is decoupled from the other components. This allows for more flexibility and makes it easier to modify or replace individual components without affecting the overall system.

we have introduced a message broker, video that needs to be processed are pushed to message broker, other components works as a consumer that consume events from this message broker.

As the components communicate asynchronously through events, the system can scale horizontally by adding more instances of a component to handle a higher volume of orders.

Benefits of event-driven architecture

Loose coupling: Components in an event-driven system are decoupled from each other, as they communicate through events rather than direct requests or responses. This makes it easier to modify or replace individual components without affecting the overall system.
Scalability: Because components in an event-driven system do not have to wait for explicit requests or responses, the system can scale horizontally by adding more instances of a component to handle a higher volume of events.
Resilience: In an event-driven system, if a component fails, events can be buffered and replayed once the component is restored, allowing the system to recover from failures more gracefully.

Here are a few examples of event-driven architecture in the real world:

Payment processing: When a customer makes a purchase at an online merchant, an event is generated and sent to the payment processing system. The payment processing system processes the payment and sends a confirmation event back to the merchant system, which updates the order status.
Social media platform: Events are generated whenever a user posts a message, likes a post, or performs any other action on a social media platform. These events are then used to update the feeds and notifications of other users in real-time.
Inventory management: In a warehouse or retail environment, events can be generated whenever an item is added to or removed from inventory. These events can trigger updates to the inventory management system and trigger restocking or replenishment as needed.

Here are a few key things to keep in mind when designing an event-driven architecture:

Identify the sources of events: The first step in designing an event-driven architecture is to identify the sources of events in your system. These could be external sources, such as user actions or sensor readings, or internal sources, such as the completion of a background task.
Define the events: Next, you should define the events that will be used to communicate between components in your system. This includes the structure and content of the events, as well as the format in which they will be transmitted (e.g. JSON messages over HTTP).
Choose an event delivery mechanism: There are several options for delivering events in an event-driven system, including message queues, publish-subscribe systems, and event buses. You should choose the delivery mechanism that best fits the needs of your system, considering factors such as reliability, scalability, and performance.
Design the event consumers: Event consumers are the components in your system that react to events. You should design these components to be as decoupled as possible from the sources of the events, and to handle events asynchronously.
Implement retries and error handling: In an event-driven system, it is important to implement retries and error handling to ensure that events are delivered reliably and that the system can recover from failures. This may include buffering events and retrying delivery on failure, or implementing compensating transactions to undo the effects of failed events.
Test and monitor the event-driven architecture: As with any system, it is important to thoroughly test and monitor an event-driven architecture to ensure that it is working as expected and to identify and address any issues that arise.

Event-driven architecture can provide many benefits, but it is not without its drawbacks. Here are a few potential downsides to consider:

Complexity: Event-driven systems can be more complex than traditional request-response architectures, as they involve asynchronous communication and may involve multiple components working together to produce and consume events. This can make it more challenging to design, implement, and debug event-driven systems.
Dependency on third-party services: Event-driven systems may rely on third-party services, such as message queues or event buses, to transmit events between components. This can introduce additional dependencies and potential points of failure.
Difficulty in testing and debugging: Because event-driven systems involve asynchronous communication and may involve multiple components working together, they can be more difficult to test and debug than traditional request-response systems.
Event ordering: In some cases, it may be important to maintain the order in which events are generated and consumed. This can be more challenging in an event-driven system, as events may be transmitted and consumed asynchronously.
Lack of transactional guarantees: In an event-driven system, there may not be the same level of transactional guarantees as in a traditional request-response system. This can make it more difficult to ensure the consistency and integrity of data in the system.

That being said, the benefits of event-driven architecture can often outweigh these drawbacks, especially in systems that require high scalability, resilience, or flexibility.

In conclusion, event-driven architecture is a powerful design pattern that can provide many benefits for modern systems. By allowing components to communicate asynchronously through events, event-driven architecture can enable more flexible, scalable, and resilient systems that can handle the demands of real-time data and distributed environments.

If you like this blog and want to read more content like this do check out my blog series and follow for email updates.

Do checkout these blogs:

Other Life changing blogs for productivity and Focus: