Request-driven vs Event-driven Microservices
The topic “microservice” has become popular among developers and organizations. There are different ways to design microservices, this article compares a couple of main microservice architectures patterns, request-driven and event-driven.
First of all, what is a microservice?
It is an application which is loosely coupled, highly testable, independently deployed, defining clear business domain boundary and maintain by a relatively small team
Request Driven Microservices
In the request-response based approach, services communicate using HTTP or RPC. These days, in most cases, this is done using REST HTTP calls.
Let's consider a simple e-commerce use case, “Order Confirmation”. As demonstrated in the above figure, Order service confirmed an order and call other microservices synchronously.
This kind of architecture named “Service Orchestration” since there is one service to manage the flow and instruct other services to perform actions. In our example, the Order Service manages the flow and it acts as the “orchestrator” for the flow.
Request Driven Microservices Benefits and Tradeoffs
Benefits
- There is a clear control of the flow, looking at the code of the orchestrator, we can determine the sequence of the actions.
Tradeoffs
- If one of the dependent services is down, there is a high chance to exclude calls to the other services.
- If there is a failure in the Orchestrator service, it will be a single point of failure. When this service is down, the entire flow won’t be executed.
- There is no easy way to recover the actions by reprocessing failed calls to dependent services.
- Rest API of the dependent services cannot be easily modified. If it is changed, consumers of the API also need to be modified. Therefore, microservices are not loosely coupled.
Event-Driven Microservices
The best way to visualize the Event-driven microservice pattern by using a choreography dance. Each dancer knows their role and what to do next, and how to react for an event, there is no instructor or orchestrator to tell what they should do. Similarly, each microservice knows their role and what to do based on an event that occurred in the application. Also, the key principle here is services execute their actions asynchronously.
Let's convert our previous request-driven application to an event-driven e-commerce application.
As you can see, Order service produces an event “OrderCreated” and publish to the event stream. (The event stream is another application that is purely designed to host event streams. Kafka and AWS Kinesis are good examples of event stream applications.)
Event-Driven Microservices Benefits and Tradeoffs
Benefits
- The producer service of the events does not know about its consumer services. On the other hand, the consumers also do not necessarily know about the producer. As a result, services can deploy and maintain independently. This is a key requirement to build loosely coupled microservices.
- As you can see in the above figure, multiple services can consume the same event. Therefore, the producer just needs to publish an event to the event stream.
- Asynchronous nature in event-driven architecture allows different services to consume events according to their processing power. This behaviour removes the tightly coupled communication mechanism in the request-response pattern. In the event-driven pattern, the producer does not need to wait for a response from the consumer.
- Much easier to add, remove or modify services. In other words, this architecture allows to plug or unplug a service without modifying other services.
- If a service goes offline while producer process events, it can replay (rewind) those events once it came back online
Tradeoffs
- There is no clear central place (orchestrator) defining the whole flow.
- Managing distributed transaction could be complex. There are multiple services that consume an event, as a result, if an exception occurred in one of the services, what should happen to the entire flow or implementing a rollback process is challenging.
A mix of two patterns
What happens if an event does not carry all the required data to perform an action. For instance, what if “OrderCreated” event does not have customer address to fulfil shipment process in “Shipment Service”.
One solution is creating a “fat event” with all the required details. However, this may not be ideal in all use cases.
Another option is introducing a hybrid architecture, a mix of event-driven and request-driven. The shipping service consumes “OrderCreated” event asynchronously. But within the shipping service, it can make a REST API call to get customer data synchronously.
Which pattern to select?
Both patterns have benefits, tradeoffs and their suitability also depend on the use case. However, if there is an opportunity to implement event-driven microservice, that will surely provide a good foundation to build loosely coupled microservices.
