Member-only story
Microservice Orchestration vs. Choreography
How event-driven architecture helps decouple your app
Microservices are all the rage right now.
They allow you to split apart your app into small chunks with clear domain boundaries. Microservices are decoupled from each other, allowing them to be changed and deployed independently of one another, which provides greater autonomy to the teams working on each microservice.
They also provide easier ways to scale heavily-used parts of the app without having to scale up the entire monolith.
It’s easy to see why microservices are appealing. However, microservices also bring with them a lot of complexity, from data consistency to communication to logging to service discovery.
It’s the challenge of communication between microservices that I’d like to address today.
Two Modes of Collaboration
What do you do when microservices need to talk to each other? Ideally, all communication should be asynchronous. Additionally, any sort of interaction between microservices should not tightly couple them together. Otherwise, you lose out on the benefits of independent changes and deployments.
There are two main modes of collaboration we can reach for: orchestration (request/response) or choreography (event-driven).
With orchestration — or the request/response pattern — a central service tells everything what to do. It makes requests to other downstream services to ensure that all the right things happen, and the downstream services respond to these requests.
With choreography — or event-driven architecture — the first service simply emits an event. Various services can subscribe to these event channels, and when they see a particular event emitted, they can respond however they would like.
An Example: E-Commerce Checkout
Let’s consider an example to better understand these two paradigms.
Imagine we have an e-commerce site. When a customer completes the checkout process, a few things need to happen:
- We need to send an email to the customer with their order confirmation.
