The Event-Driven Architecture is an architectural pattern that helps build scalable and fault tolerant applications, 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. Until I’ve switched to Zalando, a giant European E-commerce company where i had the pleasure to work some new architectural concepts that have just fascinated me. One of them is the Event-driven architecture and needless to say that exploring new ideas makes you a better developer and more confident with yourself as a professional software engineer. So what is an Event-Driven Architecture?
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 there are components of the application that emits events which other parts of the application consume and respond to.
An event is something that occurred in the application that also represent a change in it’s state and other components can react then to such events.
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’ve split out our application into separate components with single-responsibility principle allowing each functionality to be more independent and therefore scalable and fault tolerant.
We can now increase the resources for the components that are doing heavy processing without increasing it for all the application, also when a service like the notifier is down, it will not affect the application normal workflow.
When a user attempts to Sign-in, the Sign-in Service will emit an Event called UserSignIn and send it to the event bus then it will be consumed by the downstream components that will react accordingly to it.
When to use it
I’m a firm believer that simple always win. If you can deliver a value using a simpler method or an existing service, then by all means do it and don’t reinvent the wheel.
It’s the same thing for Event-driven architecture, if the functional and non-functional requirements for the application to build are so simple that they can be implemented using a monolithic approach then event-driven architecture would be an overkill.
Otherwise if we have to build an application that have demanding demanding requirements like 99% uptime and fault-tolerance and scalability then you got the right architecture to implement.