Mediator acts as an intermediary between components in the code, and this leads to very loose coupling between various components. This allows us to make minimal changes to the code, as we only need to change the interaction between the mediator and the component which is being extracted into its own microservice.

Let's look at an example. We have a monolith, which is defined by Codebase A. It consists of five components—Component 1 through Component 5. We realize that Component 1 and Component 2 rely on interacting with Component 5, while Component 2 and Component 3 rely on Component 4. If Component 1 and Component 2 were to directly call Component 5, and similarly Component 2 and Component 4 were to directly call Component 4, then we would create tightly coupled components.

If we were to introduce a function that takes input from the calling components and calls the necessary component as a proxy, and if all data were passed using well-defined structs, then we would have introduced the mediator design pattern. This can be seen in the following figure:

Now if a situation arises where we might need to separate one of the components into its own separate microservices, we only need to change the implementation of the proxy function. In our example, Component 5 is segregated into its own separate microservice, and we have changed the implementation of the proxy function mediator 1 to communicate with Component 5 using HTTP and JSON instead of communicating via function calls and structs. This is illustrated in the following figure: