Integration Patterns in a Microservice Architecture

One of the toughest challenges of microservices is connecting all the nodes to make them collaborate. For example, the Cart service of our e-commerce application would make little sense without some Products to add, and the Checkout service would be useless without a list of products to buy (a cart). As we already mentioned, there are other factors that necessitate an interaction between the various services. For example, the Search service has to know which Products are available and should also ensure it keeps its information up to date. The same can be said about the Checkout service, which has to update the information about Product availability when a purchase is completed.

When designing an integration strategy, it’s also important to consider the coupling that it’s going to introduce between the services in the system. We shouldn’t forget that designing a distributed architecture involves the same practices and principles we use locally when designing a module or subsystem. Therefore, we also need to take properties such as the reusability and extensibility of the service into consideration.

The API proxy

The first pattern we’re going to show makes use of an API proxy (also commonly identified as an API gateway), a server that proxies the communications between a client and a set of remote APIs. In a microservice architecture, its main purpose is to provide a single access point for multiple API endpoints, but it can also offer load balancing, caching, authentication, and traffic limiting, all of which are features that prove to be very useful to implement a solid API solution.

This pattern shouldn’t be new to us because we already saw it in action in this chapter when we built the custom load balancer with http-proxy and consul. For that example, our load balancer was exposing only two services, and then, thanks to a service registry, it was able to map a URL path to a service and therefore to a list of servers. An API proxy works in the same way; it’s essentially a reverse proxy and often also a load balancer, specifically configured to handle API requests. The illustration below shows how we can apply such a solution to our e-commerce application.