Should microserivce has operations that only forward operation to another microservice?

Question

Say if we have two microservice info-manage and file-service, if our user want to upload a avatar. Should the request be routed by gateway directly to file-service or info-manage? From cohesion perspective, all other info was handled by info-manage service, its makes more sense that info-manage handles the uploading request and simply forward the request to file-service. From performance perspective, thats was totally waste of bandwidth and cpu.

Answer 1

From what I understand your info service is responsible to manage user information, have some logic regarding that and store it. And then you have a file service that contains the logic to handle files (which you don't have in the info service).

So here is my feeling on your case :

First because you have a gateway your choice should be transparent to the user so he just have to call a specific endpoint to upload this file.

Second the choice of which service will handle the request depend on the logic :

1. Does the user send information along the file content ? In this case you'll have some logic to apply in info service and I would suggest that you call it, apply the logic and it will then make a request to the file service to store the file (at this point it can be relevant to think about whether it is interesting for you to store the user information file within a general file storage service or keep it in the info database to avoid this internal call)

2. If you just send a file and don't expect that info service apply logic e.g. to keep track of which user info file was added then just call directly file service.

As I said this if my feeling from working with services until now, I hope you'll get more answer to help you clarify this.

Answer 2

It depends on whether you are using an orchestrated approach or a choreographed one. In either case I don't see that there is much difference between either network bandwidth or cpu usage as essentially the same amount of work is being carried out. With the exception of if you use your client as the orchestrator, in which case you are causing some more overhead via potentially extra round-trips from client->server

In an orchestrated approach, the endpoint for Avatar operations on your gateway is the orchestrator for the workflow, so it will basically run the process by

1. Talking to the info-manage service and then

2. Talking to the file-service

   • One advantage of this approach is that you can manage this operation with some kind of transactional semantics (i.e. if either sub-operation fails the entire operation fails) with relative ease.
   • So it's a great way of doing things when you need the operations to be synchronous from the client's perspective. i.e. I POST to the Avatar endpoint and I expect a synchronous OK/FAIL response.
   • You can also use the client as the orchestrator, instead of the gateway, but that comes with its own set of problems and I wouldn't recommend it because it's effectively making your back-end abstraction leaky and forcing clients to understand your internal workflows. In addition it means more client-server roundtrips, thus more bandwidth.

In a choreographed approach, your gateway is a little less involved, it serves only as an entry point into your overall system, and it doesn't orchestrate any workflows, it just sends messages to whoever is interested that such and such a thing is needed. So for example it might send a message into a queue e.g.

{"user":"johndoe" ,"avatarName":"batman", "avatarImage":"[binary data]"}

• Both the info-manage and file-service are listening for messages like this and upon receipt are doing whatever it is they do with that information (or the subset of that information that they care about).
• This is a really scalable way of running things and is great when you have a system that you want to be fully asycnchronous even from the client's perspective, i.e. I POST to the Avatar endpoint and I'll check later or wait for a message telling me OK/FAIL.
• Bear in mind that error handling and rollback become more problematic in this case.

Personally I prefer by default the orchestration approach because it makes things simpler to develop initially; but choreography is also a great approach.