As the name suggests, this pattern is derived by one entity, like the conductor in an orchestra. The conductor's work is to ask the services to work as the signals, and the services will respond to that. Think of a team of musicians who are asked to perform. Everyone knows their jobs and will do it well, but how do they all know what beat or string to play at what time? With the hand flow of the conductor, each musician knows when to play which instrument, and it becomes a performance.

The same concept is applied here in the microservices pattern. There will be a mediator service that will act as the brain or conductor of the orchestra (number of microservices assembled). This mediator service will trigger and ask each microservice to start the action. All microservices should be working towards a single business purpose.

The mediator service works by sending messages to the desired services. These messages can be sent through HTTP calls or socket calls. The point to note here is that this pattern can be synchronous or asynchronous. Normally, in this scenario, individual services are not designed to talk to each other. Modifying the workflow can be easy with orchestration. In orchestration, the protocol should not be the boundary. The mediator service should be capable enough to talk to different services in a different protocol, such as with service A it is talking on HTTP and with service B it is talking with XML/RPC protocol. An intelligent API Gateway pattern explained in Chapter 2, Defining Microservice Components, can play the role of that mediator service.

There are challenges in this approach. Here, the mediator service becomes the central authority, and all the logic starts residing here, which is not a good microservice design. Logic inside the mediator service leads to lots of dependency between services. For example, there could be logic in the mediator service that if service A responds, then call service B. In this scenario, blindly calling service B is dependent on service A.

In the preceding example, the mediator service first checks its purchase history and bank details. Then, it asks the decision service to take a decision. One can always know the status of his or her application, but as mentioned earlier, logic is residing in the loan service now, which will start hitting the system while scaling.

Running, maintaining, and keeping this mediator service up is the cost of this pattern, but another thing is that it becomes the single point of failure in the whole architecture. This can be handled with better tooling and cloud-based techniques such as scaling, clustering, and so on. In addition to this, the orchestration model is not easy to implement in a complex domain. If you have one decision maker or controller, it becomes hard to follow the distributed design.