Enterprise Approaches to Microservices: Choose Yours Wisely


There is no lack of software product development best practices. However, what matters most for your company is that you embrace a practice that is a good fit for you. The challenge is to figure out the right execution strategy for it.

We spoke previously about why the microservices architecture turns out to be a hit among leading enterprises, highlighting how it advocates breaking large monolithic applications into micro units while streamlining and accelerating development. In this post, we will go a step further to introduce you to the right approaches to microservices.

  1. Point to point approach – Directly invoking services
  2. API gateway approach
  3. Message broker approach

The Point to Point Approach: Directly Invoking Services

In this approach, the entire message routing logic lies on the endpoints, and the services can communicate directly. Here, each of the microservices exposes  REST APIs wherein a given microservice or an external client can invoke another microservice through its REST API. Take a look:



  • This model works for relatively simple microservices-based applications. However, with the rising number of services, this model will eventually become more complex.
  • It does not require API Gateway configuration.


  • The non-functional requirements, like end-user authentication, throttling, monitoring, etc. need to be implemented at every level of the microservice.
  • Due to duplication of common functionalities, each microservice implementation can become complex.
  • You cannot establish a control over the communication between the services and clients (even for monitoring, tracing, or filtering).
  • The direct communication style is considered a microservice anti-pattern.

The API Gateway Approach

The API gateway approach offers a lightweight message gateway as the main entry point for all the clients/consumers. It implements the common non-functional requirements at the gateway level.

In general, an API gateway allows you to consume a managed API over REST/HTTP. Therefore, here you can expose your business functionalities (which are implemented as microservices) through the API-GW, as managed APIs.

This combination of microservices architecture and API-Management gives you the best of both worlds.

API gateway approach


  • It allows you to identify the required abstractions at the gateway level for the existing microservices. For example, rather than providing a one-size-fits-all style API, the API gateway can expose a different API for each client.
  • It supports lightweight message routing/transformations at the gateway level.
  • This approach provides a central place to apply non-functional capabilities such as security, monitoring and throttling.
  • With the use of API-GW, the microservice becomes even more lightweight as all the non-functional requirements are implemented at the gateway level.
  • It allows separation of concerns: the microservices can focus on business features, and API Gateway provides protection/common feature layer and minimizes service change impacts.


  • The SPOF may create a bottleneck.
  • You can potentially face a performance tradeoff from the processing time in API Gateway and more network hops.

The Message Broker Approach

The microservices can be integrated with an asynchronous messaging scenario, such as one-way requests and publish-subscribe messaging that uses queues or topics.

A given microservice can be the message producer and it can asynchronously send messages to a queue or topic.

Then the microservice can consume messages from the queue or topic.

Message broker approach


  • This approach distinguishes message producers from message consumers, and the intermediate message broker will buffer messages until the consumer is able to process them.
  • Producer microservices are completely unaware of the consumer microservices.
  • The message has a clear visual flow.


  • Due to the dispersed and autonomous nature of messaging-based microservices, it can be difficult to get a clear view of the flow of messages within the system, this could lead to debugging challenges.
  • As compared with the pipeline approach, the business logic of the system is harder to manage.


You should be aware of the best approaches before making your decision. Now you are in a position to weigh the pros and cons of each approach and select the perfect one for your enterprise. In the next part of the series, we will share the approach that we chose.

We adhere to the best engineering practices to deliver the best to our customers.

If you are looking for any help on building any digital solution for better customer or employee engagement, this an area where we can help. Please contact us at [email protected].

Sunil Goyal

About the Author

Sunil finds his forte in defining software architectures. With over 10 years of experience in the industry, he has contributed to several leading projects. He loves spending time with friends and ensures to do so even on a hectic day.

Leave a Comment

Pin It on Pinterest


Articles written by industry experts about things that matter most in designing and building Digital Products and Platforms for Startups and Enterprises.

Subscribe to our

Digital Insights

Follow us on:

Aw, yeah! That was a smart move.

We have sent a short welcome email your way.