Hello Stackers, In building a system with a microservices architecture, we need to determine the right method to bridge communication between separate and stand-alone services, but sometimes there are services that need to connect to other services to complete a business process.
Let’s just say we have an eCommerce application using a microservices architecture in which there are ordering, payment, notification, wish list, and review applications.
In the ordering process, each related service will communicate with each other to complete the order process carried out by the customer. The booking application will communicate with the payment application to create an invoice, then communicate again with the notification application which will send an email to the customer.
In general, there are two types of integration methods in microservices:
- API-Driven Architecture
- Event-Driven Architecture
Event-Driven Architecture
Before going any further, we should know what “event” means.
An event is a thing that happens, especially something important.
If it is interpreted in Indonesian and adjusted to the discussion of the microservice architecture, an event is an event that occurs, especially something important, for example, a change from a recognizable condition. For example, sensor data, logs, transactions, or website click events
What is event-driven architecture?
A software architecture and application design model that captures events that occur in an application to be used as an integration mechanism between applications.
How does event-driven architecture work?
In an event-driven architecture, there are three main components that are connected to each other. The three components in question are:
- Event producers detect and produce events that take place in an application and then represent those events as messages that will be sent to the process platform or message broker. Event delivery usually takes place asynchronously.
- The message broker is a component of the event-driven architecture that serves as middleware between the event producer and the event consumer. Its main task is to send the message created by the event producer to the event consumer.
- event consumer, the component that receives the message sent by the message broker, then processes it according to the command in the received message.
Choreography Pattern
Event-Driven Architecture is closely related to choreography patterns; each service or application must know what to do when something happens. Every action performed by the service must match its domain; the service will run independently to complete tasks delegated by other services. The picture below shows the checkout process that occurs when an order is made on an eCommerce system.
A choreography pattern will make it easier to develop a system. When there is a new service that needs to be implemented in the service system, you can get data from existing services just by connecting with a message broker, without having to change all the code on the service that is already available.
Okay, That’s All folks. See you in the next episode haha …
