React outside, orchestrate inside

The first hybrid patterns promote reactive patterns between different microservices and orchestration inside a service. Let's consider an example to understand this. Consider our shopping microservices example. Whenever someone buys a product, we will check inventory, calculate price, process payment, check out payment, add recommendation products, and so on. Each of these microservices would be different. Here, we can have a reactive approach between product inventory service, payment service, and recommendation products, and an orchestration approach between checkout service, process payment, and dispatch product. A collective service produces an event based on the outcome of all these three services, which can then be produced. There are several advantages and value additions, such as:

• Most of the services are decoupled. Orchestration only comes into the picture whenever it is required. The overall flow of the application is distributed.
• Having asynchronous events and an event-based approach ensures no single point of failure. If events are missed out by services, then events can be replayed whenever the service is available online.

While there are several advantages, there are some trade-offs introduced:

• If services are coupled, then they can soon become a single point of failure. They cannot be scaled independently.
• Synchronous processing can cause system blocking and resources would be occupied until the request is fully completed.