Let's suppose that I have 5 microservices, let's also name them ServiceA, ServiceB, ServiceC, ServiceD, ServiceE.

To perform an operation X communication needs to happen between these services.

And I have an API in ServiceD which is a pretty expensive API (in terms of execution time and response size) and this API gets consumed by ServiceA at the beginning of the operation X. (NOTE that the response for this API is based on users, so the response will be different for different user)

Based on the response received the ServiceA takes some decision and calls subsequent services:


ServiceA --> (req.) ServiceD (expensive API)
ServiceA <-- (resp.) ServiceD
ServiceA --> (req.) ServiceB
    ServiceB --> (req.) ServiceC
    ServiceB <-- (resp.) ServiceC

    ServiceB --> (req.) ServiceE
        ServiceE --> (req.) ServiceD (same expensive API called earlier in the same flow)

Now, the ServiceE needs to call the same expensive API of ServiceD which was earlier called by ServiceA in the same flow (by same flow I mean in the chain of API calls to perform X for a user).

But, since this is a very latency-sensitive flow, so calling this API again will result in an increase in the latency which is an unwanted situation.

Possible solutions I can think of:

  • Pass the initial response from the ServiceD to the subsequent API calls and consume the required data from the request in the ServiceE, then no need to call the expensive API.

    • But, concerns here:
      • More network bandwidth is consumed coz of the large payload size being passed b/w different services.
      • Security concerns like mutation of data in the subsequent API calls between different services.
      • Serialization/Deserialization cost for large payload?
  • Cache the response of the expensive API for the user.

    • But, concerns here:
      • How scalable would it be? since caching will be happening for many users.
      • How much of improving in latency with caching give, if I go ahead with any cache service running on a separate cluster?

What solution do you propose to reduce the latency?

  • I am wondering why are down votes attracting this question? Any comment on the improvement of the question will be helpful :). Commented Apr 21, 2020 at 12:21

1 Answer 1


First find out what dominates in the latency of ServiceD, the execution time or the time it takes to transfer all that data. Then try to optimize that aspect.

Caching will mostly help in optimizing the execution time. You can tune how much memory that consumes by how long a cached request stays valid. You could make that short enough that the cached response only gets used in the sequence you described, but gets purged almost immediately after.

If the latency is mostly in the transfer time, you should check if all that data is necessary or if you can create a smarter API that is equally useful with less data. Or you should arrange for more bandwidth between the affected services.

  • well, the API in ServiceD is pretty expensive and so it causes latency. The reason it's expensive is that the API itself calls different APIs and mostly time gets consumed in-network calls. So, more optimizing that API isn't possible, coz its already optimized. Also, thanks for your response. Commented Apr 21, 2020 at 9:19
  • @AmitUpadhyay, I would list what you mention under "execution time" for ServiceD. That time itself can't really be reduced, so caching is an option to look into. Commented Apr 21, 2020 at 12:13

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.