If millennial microservices had social networks

In the previous article we talked about how to solve functional scalability problems with a microservices-based approach, especially when we are in a monolithic hell. Let's remember that our protagonist Sarah, tech leader in the white kitchen app, has decided that it's time to radically change the architecture so that in the short term the application is really sustainable.

Along with her team they have started an exhaustive mapping of all the services that make up the white kitchen application. Following the principles presented in the previous article, they have managed to divide the business logic into 6 microservices from the orders, through the payment system and creating integrations with the dark kitchen’s APIs, as shown in the diagram

But when you have all the microservices already designed, how do you make those microservices work together harmoniously? It is at this point that understanding the different types of existing communications can help such an architecture to scale organically instead of entering a disastrous loop of corrections in the future. Microservice communication is essential for product scalability.

Types of communications

In general, there are 2 types of communications as shown in the previous diagram

• Invocations: corresponding to those where a microservice calls a method of another microservice by means of messages.
• Subscriptions: which correspond to those where a microservice publishes events in real time and different microservices subscribe to execute some action based on these events.
  

But this turns out to be mere theory, since in reality this differs a little from its implementation because messages must be sent and processed. This type of execution is known as brokerless architecture and is where the microservice applies a system to be able to process each of the messages received.

The main problem of this architecture is the resources needed to process these messages. Each microservice must implement a queue system to read the messages, but also a backup system where, in case the microservice fails, the message queue can continue working while the microservice is restored.

For this reason, there are architectures that use message broker, which corresponds to a service that has the objective of reading each message and forwarding it to the destination microservice. This type of architecture allows efficient data management and also makes the system resilient to failures since multiple instances of the message broker can be generated.

This has made the message broker based architecture one of the most widely used and is considered for most microservice communication patterns.

Communication patterns for microservices

At this point we have the microservices and the architecture using a message broker, so we just need to start designing the interactions. Let's imagine for a moment that a user makes an order in the White Kitchen app, the application should follow the following steps in order to complete an order

1. The system receives a new order
2. It checks for availability of the requested product
3. Once availability is confirmed, the order is paid for.
4. Finally, the order is placed
   

In order to solve this flow, we will introduce 2 important patterns

Microservices pattern: Choreography

Choreography is a pattern where each microservice has the functions completely defined in a determined flow and these work in a coordinated way. The following diagram represents how Choreography works in the flow of handling orders:

Microservices pattern: Orchestration

Orchestration corresponds to the pattern where a microservice takes control of the flow and functions as the control center for this interaction, orchestrating the work of each of the microservices involved. The following diagram represents how Orchestration works in the flow of handling orders

We hope this overview gives you a general idea about how microservices can communicate. We hope this will be useful if you are starting a new project and want to learn the basics of communication between them. Microservices are changing the way projects are developed and it is necessary to understand them.