To understand event-driven architecture, you need to understand the concept of “events”.

An event is an action that triggers either a notification or some kind of change in the state of the application. A light has been switched on (notification), a user changed his address (state change), or one of the users changed their phone number (state change).

The basic idea is to identify which such “events” are relevant to the business / use case in your software. Then you can build your event-driven architecture.

In the erstwhile classic three-tier applications, the core of our system was the database. In EDA, the focus is now shifted towards the events and how they are flowing through the system.

When is it preferable to use EDA?

  • You want to maintain Availability in your SaaS / software – Instead of one application, you may have many, dozens maybe in large applications even hundreds of linked services, and each and one of them has to be ready to do its job 24/7. Most often services can be horizontally scaled to multiple instances, sometimes across multiple data centers, making it highly-available. All the requests coming into this specific service will be routed evenly across all instances. So if one instance goes down, we will want another instance to take its place and avoid any downtime for end users. Availability is all about making sure that there is at least one instance of the service up and running, ready to serve incoming requests.
  • Scalability is required as your application grows – Scalability, is focused on performance. If one application is overloaded, then we can easily create new instances of that application to accommodate the increased number of requests.
  • Maintaining single source of truth – Before microservices, all the data used to reside in a single place, typically some sort of relational database. But if your application is using multiple services, they may often share a database. Using a distributed source of truth really helps maintain clean architecture and improve your SaaS resilience and performance.
  • Need Synchronous application – In a typical request-response scenario, the client waits for the server to respond. In a microservices architecture such setting deteriorates the application performance significantly.

For business the most evident benefits are ease of scaling the applications, ease of maintaining and enhancing their software products and mostly importantly maintaining availability of SaaS / cloud applications.


Leave a Reply