top of page

Microservices: Orchestration vs. Choreography

Microservices orchestration

Orchestration promotes a centralized approach in which a controller process calls each of the services involved in the transaction, monitors the results and then either calls the next service or performs a rollback. To use the purchase example, the action CreateOrder() appears like a single, logical transaction, but within it the orchestrator manages a complex series of service calls, sometimes called a saga. When the orchestrator aggregates a series of lower-level calls to help build a webpage, it's called the back ends for front ends pattern.

While orchestration offers tight control of each step in the process, this centralized approach makes services dependent on others. If one service in the chain fails, then the process fails and must start over. Also, if the orchestrator goes down, the whole process fails.


  • Easy to maintain and manage as we unify the business process at the center.

  • In synchronous processing, the flow of the application coordinates efficiently.


  • Creating dependency due to coupled services. For example, if service A is down, service B will never be called.

  • The orchestrator has the sole responsibility. If it goes down, the processing stops and the application fails.

  • We lose visibility since we are not tracking business process.

Microservices choreography

Orchestration is not the only way to solve the saga problem. Services can communicate with each other without any controller. One of the key differences between orchestration and choreography is the asynchronous nature of choreography. Rather than sending a request, blocking and waiting for the response, a web service simply drops a request on the event bus and the bus distributes work between the connected components of an application. Each service works independently and consumes the data that relates to it to perform its task.


  1. Faster processing as no dependency on central controller.

  2. Easy to add and update. The services can be removed or added anytime from the event stream.

  3. As the control is distributed, there is no single point failure.

  4. Works well with agile delivery model, as teams work on certain services rather than on entire application.

  5. Several patterns can be used. For example, Event sourcing, where events are stored, and it enables event replay. Command query responsibility segregation (CQRS) can separate read and write activities.


  1. Complexity is the concerning issue. Each service is independent to identify the logic and react based on the specific data in the event stream.

  2. Business process is spread out, making it difficult to maintain, manage the overall process.

  3. Mindset change is prerequisite in the asynchronous approach.

Difference Between Orchestration and Choreography

The following table is a summary of the differences between the two concepts:

The Tech Platform



bottom of page