# Orchestration vs Choreography > Designing effective communication between services is one of the challenges of working with distributed systems. More centralization or less? More coupling or less? Here's how orchestration and choreography compare, and a framework for deciding which one to use. Published: 2023-08-26. Author: Milan Jovanović. Canonical: https://milanjovanovic.tech/blog/orchestration-vs-choreography Orchestration is centralized and command-driven: one service acts as the orchestrator and tells the other services what to do. Choreography is decentralized and event-driven: each service publishes events, and other services react to the ones they care about. Orchestration is easier to monitor and troubleshoot, while choreography gives you looser coupling. More than 63%+ of organizations said in a [Dzone survey](https://dzone.com/articles/new-research-shows-63-percent-of-enterprises-are-a) that they are adopting **Microservices** for some or all of their applications. As more businesses adopt the use of Microservice architectures, we as developers have to become more skilled with Microservices communication. Working with **distributed systems** is both fun and challenging at the same time. One of those challenges is designing **effective communication** between services. More centralization or less centralization? More coupling or less coupling? More control or less control? These are only a few questions you need to answer. In this week's newsletter, we will: - Break down **Orchestration vs. Choreography** - Understand key differences and **tradeoffs** between them - Create a framework for deciding which approach to use Let's dive in! ## What Are Microservices? [**Microservices**](https://milanjovanovic.tech/blog/microservices-dotnet-getting-started) are a **software architecture** style where an application is built from small, autonomous services. Each microservice serves a distinct purpose and can be independently deployed. You probably already know this, so this is a quick refresher. ![Complex dependency graphs for Amazon and Netflix microservice architectures](https://milanjovanovic.tech/blogs/mnw_052/microservices_hell.png) Here are the key tenets of Microservices: - Independent development - Deployment independence - Technological freedom - Scalability - Resilience A significant challenge is designing effective inter-service communication within this distributed environment. Inside a Monolith system, communication happens through direct method calls. This is a straightforward approach that works well when all components live within a single process. However, this doesn't work with microservices. ## Orchestration - Command-driven Communication **Orchestration** is a centralized approach to Microservices communication. One of the services takes on the role of the **orchestrator** and coordinates the communication between services. Orchestration uses **command-driven** communication. The command communicates the intent of the action. The sender wants something to happen, and the recipient doesn't need to know who sent the command. An example of orchestration can be a [**Saga implemented with RabbitMQ.**](https://milanjovanovic.tech/blog/implementing-the-saga-pattern-with-rebus-and-rabbitmq) ![Orchestration flow where Ordering commands Inventory, Payment, Notification, and Shipping services](https://milanjovanovic.tech/blogs/mnw_052/orchestration.png) It has some nice **benefits**: - Simple - Centralized - Ease of troubleshooting - Monitoring is straightforward **Orchestration** is typically **simpler** to implement and maintain than choreography. Because there is a central coordinator, you can manage and monitor service interactions. This, in turn, improves troubleshooting, as you know where to look when something goes wrong. The **drawbacks** of orchestration are: - Tight coupling - Single point of failure - Difficulty adding, removing, or replacing microservices ## Choreography - Event-driven Communication **Choreography** is a **decentralized** communication approach. Choreography uses [**event-driven**](https://milanjovanovic.tech/blog/event-driven-architecture-in-dotnet-with-rabbitmq) communication - as opposed to orchestration, which uses commands. An **event** is something that has happened in the past and is a fact. The sender does not know who will handle the event or what will happen after processing it. I talked about events in-depth in the newsletter about [**publishing domain events.**](https://milanjovanovic.tech/blog/how-to-use-domain-events-to-build-loosely-coupled-systems) ![Choreography flow where services exchange order events through a message broker](https://milanjovanovic.tech/blogs/mnw_052/choreography.png) The most important **benefits** of choreography are: - Loose coupling - Ease of maintenance - Decentralized control - Asynchronous communication **Choreography** allows microservices to be **loosely coupled**, which means they can operate independently and asynchronously. This makes the system more scalable and resilient. A failure of one microservice won't necessarily affect microservices. Of course, there are **downsides** to choreography: - Complexity - Monitoring is difficult - Difficulty troubleshooting It's more complex to implement and maintain than orchestration. Effective monitoring is the biggest challenge from my experience. ## The Crossroads: Which One Should You Choose? So, how do you know which one to pick for your system? I always start with the requirements of the system I'm building. And then, I look at the pros and cons of orchestration vs. choreography. Here's a small framework to help you decide. **Orchestration** excels when: - You need to wait for the completion of intermediate steps (such as credit card payment confirmation) - You need to make a conditional choice of subsequent steps - The process must be carried out atomically (entirely or not at all) - The process needs to be centralized in one place for monitoring This also means you will need a central database managed by the orchestrator to handle all workflow-related state. **Choreography** works best when: - The process can rely on the input message without needing additional context - Steps clearly follow one another - Progress is made in one direction You can benefit from increased flexibility (such as modifying individual steps in isolation) Unfortunately, choreography can make it difficult to trace, debug, or monitor the processes triggered by an event. And the larger the event stream is, the more challenging it becomes. So, think carefully before opting for orchestration or choreography. Both approaches bring their advantages but also downsides. ## Takeaway **Orchestration** defines a sequence of steps that each microservice must follow. This is great for identifying and addressing complex service interdependencies. Another benefit is that business logic can be managed and monitored in one place. **Choreography**, on the other hand, is a decentralized technique for microservices communication. Each service can operate independently while still being part of the larger architecture. To decide which approach to use, you should observe your system and identify what you stand to gain or lose. Everything is a tradeoff. There's also an **alternative approach** I want to mention. You could go for a **hybrid approach** that integrates orchestration and choreography. In a **hybrid approach**, you decide which communication technique to use for a specific workflow. Some workflows can benefit from orchestration, and others can benefit more from choreography. Hope this was helpful. I'll see you next week! --- ## Frequently asked questions ### What is orchestration in microservices? Orchestration is a centralized communication approach where one service acts as the orchestrator and coordinates the other services using commands. It is simpler to implement and monitor, but it introduces tight coupling and a single point of failure. ### What is choreography in microservices? Choreography is a decentralized, event-driven communication approach. Services publish events describing facts that already happened, and other services react to them independently. This gives you loose coupling and asynchronous communication, at the cost of harder monitoring and troubleshooting. ### What is the difference between orchestration and choreography? Orchestration uses command-driven communication with a central coordinator that tells services what to do. Choreography uses event-driven communication with no central control, where each service reacts to events on its own. Orchestration is easier to monitor; choreography is more loosely coupled. ### When should I use orchestration instead of choreography? Use orchestration when you must wait for intermediate steps to complete, make conditional choices between steps, run the process atomically, or monitor it in one central place. The orchestrator then keeps all workflow state in a central database. ### Can I combine orchestration and choreography? Yes. In a hybrid approach you decide per workflow which communication technique fits best. Some workflows benefit from the central control of orchestration, while others benefit from the loose coupling of choreography.