This is a good way to have tighter flow control when there's a need for synchronous communication and processing. There are a few drawbacks with this—if the first service isn't responding, the other services can't be called. That is, it creates a kind of coupling that results in unwanted dependency issues. The orchestrator becomes the single point of failure, and hence the recommendation is to go for clustered orchestration. Synchronous communication blocks other service requests.

The following diagram illustrates how the orchestration process gets accomplished through the participation of disparate and geographically-distributed microservices:

This composition model typically doesn't address failure cases. Most of the time, the service request is being attended. The failure rate is mostly one percent. The best practice is that if there is a failure, one or other viable counter measures, such as compensation, has to be initiated immediately in order to wriggle out of the chaos. The retry and repair activities are the other mechanisms to ensure business continuity. Data and disaster-recovery capabilities have to be in place to reduce the data loss in order to maximize business profits. Considering the drawbacks of service orchestration, the service choreography (this is explained in detail in the subsequent sections) is gaining a lot of attention.