Communication between microservices

In the preceding section, we separated our Order module into Order Services and discussed how we can break down the foreign key relationship between ORDER and PRODUCT tables.

In a monolithic application, we have a single repository that queries the database to fetch the records from both ORDER and PRODUCT tables. However, in our upcoming microservice application, we will segregate repositories between Order Service and Product Service. With each service having its respective database, each one would access its own database only. Order Service would only be able to access order Database, whereas Product Service would be able to access product Database only. Order Service should not be allowed to access product Database and vice versa. Refer to the following image:

In the preceding figure, we see that our UI is interacting with Order Service and Product service via API gateway. Both the services are physically separated from each other and there is no direct interaction between these services. Communication performed in this manner is also referred to as communication that is based on the API Gateway Pattern.

The API gateway is nothing but a middle tier via which the UI can interact with the microservices. It also provides a simpler interface and makes the process of consuming these services simpler. It provides a different level of granularity to different clients as required (that is browser and desktop).

We can say that it provides coarse-grained APIs to mobile clients and fine-grained APIs to desktop clients, and it can use a high-performance network underneath its hood to provide some serious throughput.

The definition of granularity from wiki: