Spring Boot Kafka Microservices - #2 - What is Event-Driven Architecture?


Welcome to Spring Boot Kafka Event-Driven Microservices Series. In this lecture, we will take a look into 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.

Lecture - #2 - What is Event-Driven Architecture?


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 on to 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.

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.


Free Spring Boot Tutorial | Full In-depth Course | Learn Spring Boot in 10 Hours


Watch this course on YouTube at Spring Boot Tutorial | Fee 10 Hours Full Course

Comments