What I usually do, for a variety of reasons, is to send all of the calls to one server, and if that server needs to "ask for help from someone else," then let it be the one to do it.

The basic reason for this is ... timing. If you've got several different asynchronous request streams going on at the same time to different servers, then you can lose control of what's going on in a great big hurry. This creates software that's very, very difficult to debug ... stuff that's going to "fail in front of the end-user." Not what you want.

Also... it's usually the case that the host-side components need to be aware of each other. They probably need a reliable, trustworthy way for "the left hand to know what the right hand is doing." Well, the client-side is neither reliable nor trustworthy.

So... let there be a "single point of contact" for the client-side application to talk to. If there needs to be communication among server-side components, let them securely discuss things among themselves without further involving the client.

It's not a matter of "is it possible to do it this-way or that." (The answer is, "yes.") It comes down to what is most likely to be most "RASS = Reliable, Available, Secure, Serviceable."