I've such microservice architecture as below. I want execution service to get some information from storage and assignment services. I want to use MVC App like an API Gateway and handle all microservice communication. However, that creates an overhead especially for big files since it first has to go to API gateway over network then to my execution service.

My question is whether it is ok to communicate between microservices directly via REST calls or will it eventually turn into spaghetti architecture if I do that ?

How shall I connect the arrows...?

Thanks in advance.

enter image description here

2 Answers 2


Let's start with the fundamental question:

Is it OK to communicate between microservices directly via REST calls?

Short answer: yes, but...

I just want to clarify a couple concepts. An API gateway is there to redirect requests to one of the potentially multiple instances of a microservice you have running. The gateway handles the load balancing, etc.

If you want direct connect between microservices, you still need the loadbalancing. It all depends on your infrastructure how you handle it. For example, the way you accomplish that with Kubernetes, Spring Cloud infrastructure, or Consul will be slightly different.

The reality is that any one of your microservices can go into a partial failure, where it ceases to respond to new requests and is essentially "stuck". It can be for many reasons like memory pressure and garbage collection gone into hyperdrive, an endless loop that didn't get caught in testing, etc.

The bottom line is:

  • The more services you chain together in one call increases the chance that one of those things can go wrong
  • Using a circuit breaker pattern helps mitigate the issue with stuck microservices, allowing you to fail gracefully
  • I recommend using some form of Open Tracing to debug problems in this scenario
  • Asynchronous calls through an message queue might greatly improve the responsiveness of your API

The sooner you can send a meaningful response to your caller, the more responsive your application will feel. There may be further processing that needs to be done, but the user doesn't need to sit and wait for everything to be completed as long as they can trust that it will be completed.

As a general rule of thumb:

  • Very short duration calls from one service to another are fine. Example: an authentication service calls a user management service to find the important factors to generate a session token.
  • Long duration calls from service to service are at risk of timeout. Use asynchronous communications if possible.
  • If you find yourself having to make a lot of service-to-service calls, that can be a symptom that you might not have divided the responsibilities of the services appropriately.
  • Avoid long service call chains (i.e. service 1 calls service 2 that calls service 3, etc.), perhaps asynchronous calls can simplify that.

So you main concern is whether this will turn into spaghetti architecture ? Well, why don't you use documentation !? This is a well tested practice to ameliorate these kind of matters ! Just document every process , so you will know where each arrow points to .

Additionally , on your gateway concerns .

 I want to use MVC App like an API Gateway and handle all microservice communication. However, that creates an overhead especially for big files since it first has to go to API gateway over network then to my execution service.

Have you benchmarked this using the gateway and concluded this does not meet your needs ? Then sheer theory should not get into your way. Theory is there to solve problems and not create new constraints. Just go for the direct communication and handle appropriately (with the documentation mentioned above :P ).


A gateway is a way to connect multiple apps and expose interfaces probably ( among other reasons). The fact that you will have more interfaces should be borderline insignificant if you approach the new interface as a new gateway. So from the client app's point of view there will be just two interfaces. (See Holistic vs analytical thinking..:P) . Another addition: There is a pattern called backends for frontends. Well, yours can be frontends for backends ! And still inside the micro-services ecosystem. Well, not exactly, but what I am trying to say is that in here there could be valid reason for separation of backend interfaces.

I hope I am of assistance .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.