The Event-Driven Architecture is an architectural pattern that helps in building scalable and fault-tolerant applications. You can learn more about the concepts of this architectural pattern in simple terms and examples.
Introduction
I came from a traditional Software Engineering background, working on simple CRUD applications. However, I made a switch to Zalando, a prominent European E-commerce company, where I had the pleasure of working with some new architectural concepts that truly fascinated me. One of these concepts is the Event-Driven Architecture. Needless to say, exploring new ideas not only enhances your skills as a developer but also boosts your confidence as a professional software engineer. Now, let’s dive into what an Event-Driven Architecture is all about.
Definition
Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events.
Wikipedia
Simply put, in an Event-Driven Architecture, certain components of the application emit events that other parts of the application consume and respond to.
An event represents something that has occurred within the application and signifies a change in its state. Other components can then react to these events and respond accordingly.
Event-driven architecture is used by a lot of big tech companies like Microsoft or Amazon. But when can this architecture pattern help us in our software development and based on what criteria should we choose to implement it?
What problem does it solve
Let’s start with a simple example, like a sign-in feature that needs to do the following steps:
- Receive a User sign in request with the credentials
- Verify the User credentials in the database
- Update the User Sign-in attempt in the database
- Increment the number of users online
- Notify the other devices
- Return back a HTTP Response
There are a lot of points of failures in this example, for example, if we successfully verify the user credentials during the sign-in process but we fail to notify other devices do we send a 200 and try the notification step later or we send 500 although the user have signed in successfully.
Using event-driven architecture we can decouple the steps of the monolithic approach to refactor it planning for better scalability and also fault-tolerance as demonstrated in Figure 2.
We have divided our application into separate components, adhering to the single-responsibility principle. This approach allows each functionality to operate independently, resulting in improved scalability and fault tolerance.
With this architecture, we can allocate additional resources specifically to components that require heavy processing without affecting the entire application. Furthermore, if a service like the notifier goes down, it will not disrupt the normal workflow of the application.
When a user tries to sign in, the Sign-in Service emits an event called UserSignIn. This event is then sent to the event bus, where downstream components consume it and react accordingly.
When to use it
I’m a strong believer that simplicity is often the key to success. If you can achieve the desired value using a simpler method or an existing service, there’s no need to reinvent the wheel.
The same principle applies to Event-Driven Architecture. If the functional and non-functional requirements of the application are straightforward and can be effectively implemented using a monolithic approach, then adopting an event-driven architecture might be unnecessary.
However, if the application has demanding requirements such as 99% uptime, fault-tolerance, and scalability, then Event-Driven Architecture becomes a suitable choice. It provides the necessary capabilities to meet these rigorous demands and ensures the application performs reliably in challenging scenarios.