What Is Event-Driven Architecture?

📘 Premium Read: Access my best content on Medium member-only articles — deep dives into Java, Spring Boot, Microservices, backend architecture, interview preparation, career advice, and industry-standard best practices.

🎓 Top 15 Udemy Courses (80-90% Discount): My Udemy Courses - Ramesh Fadatare — All my Udemy courses are real-time and project oriented courses.

▶️ Subscribe to My YouTube Channel (176K+ subscribers): Java Guides on YouTube

▶️ For AI, ChatGPT, Web, Tech, and Generative AI, subscribe to another channel: Ramesh Fadatare on YouTube

 In this short article, we will discuss what event-driven architecture is.

YouTube Video

What Is Event-Driven Architecture?

Event-driven architecture (EDA) is a software design pattern in which decoupled applications can asynchronously publish and subscribe to events via an event broker/message broker.

In an Event-Driven Architecture, applications communicate with each other by sending and/or receiving events or messages.

Event-driven architecture is often referred to as “asynchronous” communication. This means that the sender and recipient don’t have to wait for each other to move onto their next task. Systems are not dependent on that one message. For instance, a telephone call is considered synchronous or more along the lines of the traditional “request/response” architecture. Someone calls you and asks you to do something, the requestor waits while the responder completes the task, and then both parties hang up. An asynchronous example would be text messaging. You send a message and in some cases, you don't even know who you are sending it to or if anyone’s listening, but you are not waiting for a response.

Event-driven apps can be created in any programming language because event-driven is a programming approach, not a language.

An event-driven architecture is loosely coupled.

What is an Event?

An event is defined as a change of state of some key business system. For instance, somebody buys a product, someone else checks in for a flight or a bus is late arriving somewhere. And if one thinks about it, events exist everywhere and are constantly happening, no matter what industry.

Event-Driven Microservices Architecture

Event-Driven Architecture is widely used in Microservices applications.

The below diagram shows a simple Event-Driven Microservices Architecture:

In Event-Driven Microservices Architecture, all the Microservices are loosely coupled (independent of each other). 

In Event-Driven Microservices Architecture, multiple microservices use Message Broker for “asynchronous” communication between them. The Message Broker can be a RabbitMQ or Apache Kafka or ActiveMQ etc.

In above architecture, OrderService, StockService and EmailService microservices are independent of each other. OrderService is a Producer application that sends an event to the Message Broker. StockService and EmailService are Consumers who will consume the events from the Message Broker. 

Advantages Of Event-Driven Architecture

Improves Flexibility And Maintainability

One of the most important needs of an application is maintainability. Ease of maintainability comes with proper separation of concerns.

In our example above, the OrderService is only responsible for collecting the order and placing it in the queue. It does not worry about how it is going to be processed, who is going to process it, and so on.

Similarly, the StockService is only responsible for updating the stock, and the same with the other microservices.

If there is a need for an additional processing step on an order, you write a new microservice to listen on the Message Broker and easily integrate it into the system.

Such an architecture is clearly extensible, and also easily maintainable, due to the separation of concerns.

High Scalability

In Event-Driven Microservices Architecture, all the Microservices are loosely coupled (independent of each other) so you can easily scale this architecture by adding any number of microservices without affecting existing microservices.

Improves Availability

Let’s say one of the services listening for order events from the queue, such as the StockService, goes down.

In the first architecture approach of using a monolithic approach, anyone functionality going down would mean the application cannot process orders anymore.

In the case of event-driven architecture, the StockService going down would not prevent the OrderService from putting the order event into the Queue. The OrderService can notify the user of a successful request receipt.