Enterprise Approaches to Microservices: Choose Yours Wisely

DZone 's Guide to

Enterprise Approaches to Microservices: Choose Yours Wisely

It's important to embrace the best development practices that are right for your company. Learn how to choose and develop your execution strategy.

· Microservices Zone ·
Free Resource

There is no lack of software 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.


  • 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.


  • 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.

integration, microservices, microservices architecture, software architecture

Published at DZone with permission of Rohit Dogra , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}