In the previous  post in this series, we learned about the pitfalls of tightly coupled direct call microservices and how to avoid them by implementing the choreographed event-driven microservices pattern. This article will expand on a different event-driven architecture pattern. But first, a quick recap on some key concepts before we get cracking on achieving loosely coupled microservices utopia!

We established that the direct call microservice pattern leads to a tight web of coupled services which in reality leads to a distributed monolith. One way to avoid building a distributed monolith is to instead implement event-driven microservices. The golden rule of Event-Driven microservices is that all communication is asynchronous. Instead of API calls, microservices publish records of their doings, also known as events. An Event is a record of business action and must contain all information relevant to that action. Events are published to messaging infrastructure (think Kafka, RabbitMQ), and it is left to consuming microservices to figure out how to operate on them. By removing this tight coupling between services, it’s possible to truly reap the benefits offered by the microservices architecture pattern.

The choreography pattern that we explored earlier offers many of the benefits of this style of architecture, but it has its downsides too. It is difficult to add intermediary steps in a business flow, and the monitoring and observability can get complicated (although not more so than in the direct call pattern). The choreography pattern is also not suitable for business workflows that are complex and that involve a large number of services. If you have many microservices that implement complex, often changing business flows, you may be better off implementing the orchestration pattern.

What is the Orchestration Pattern?

As opposed to the choreography pattern where services emit events to a stream; and other services consume from the stream, the orchestration pattern involves a central orchestration service (or services). This orchestration service contains the entire business workflow logic, and issues commands to and awaits responses from worker microservices. Think of this as an orchestra where a central Conductor is responsible for keeping the orchestra in time and coordinating all the various players to produce one cohesive musical piece. Netflix liked this analogy so much that they even named their orchestration engine “Conductor”.

Let’s look at the same simplified business logic flow that we modeled with the choreography pattern

• An order needs to be created.
• An email with the details of the order needs to be sent to the customer.
• Inventory needs to be decreased.
• A hold needs to be placed on the customer’s credit card.

#microservices #event-driven-systems #scaling #software