Description:
Choreography and orchestration are two modes that distributed microservices can use to communicate with each another.
In choreography, every service works independently and communicates without tight control. Events flow between services without any centralized coordination. Each microservice listens for events that it is interested in and performs its own actions using an event-driven model.
In orchestration, a central service called an orchestrator controls the interaction between services. The orchestrator coordinates interactions and the order of service invokes. It acts as control flow for the business logic.
Many applications use both choreography and orchestration for different use cases. Communication between bounded contexts is often how choreography is used most effectively. Within a bounded context, you control the sequence of service integration, maintain state, and handle errors and retries. A standard guideline is to use orchestration within the bounded context of a microservice and use choreography between bounded contexts.
The following article presents an illustration of two interaction patterns, highlighting their pros and cons, and gives the advice how to select or combine them within a given context.
Choreography vs Orchestration in the land of serverless
Solution:
AWS Step Functions is a serverless orchestration service. A workflow in Step Functions is called a state machine. The state machine simplifies the implementation of common tasks and supports features like retries, handling failures, parallelization, service integrations, and observability.
Original:
Refactored:
See the CDK implementation of this pattern in Typescript on GitHub.
Advantages:
Easier to implement as one system controls the flow between components. The work flow is modelled and version controlled.
Simplifies end-to-end monitoring, reporting using built in visualization, and audit histories.
Transaction management and error management. It is easier to handle transaction errors, timeout, retries etc.
Centralized business logic. Everything is visible in one place. No need for complex architecture diagrams and supporting documents.
Considerations:
A different cost model when using an orchestration service. AWS Step Functions has two modes, Standard and Express Workflows. Standard Workflows charges per state transitions after exceeding the initial 4,000 free state transitions per month. Step Functions counts a state transition every time a step of your workflow executes. Step Functions Express Workflows can run for a maximum of 5 minutes and charges by the number of executions and memory consumption and can reduce costs in some scenarios. For example for 50K requests it costs $3.96 using the original architecture and the refactored architecture using Standard Workflows costs $4.90 and Express Workflows $3.18.
Tight coupling of services with the orchestrator.
Less flexible to add individual components. You need to test the whole system for small changes in workflow.
Applicability:
The refactoring can be applied to workflows where you want centralized control over the interactions between microservices. This can help to have a unified view of the system and to make it easier to troubleshoot and make decisions. This can be especially helpful when considering a complex architecture featuring numerous services.
Related refactoring:
Created by:
