❮ Previous Lecture
Next Lecture ❯
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.
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.
❮ Previous Lecture
Next Lecture ❯
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.
Comments
Post a Comment
Leave Comment