You seem to be quite focused on latency. Latency is not necessarily something you care about. For coarse grained logistics information, for example, it doesn't

You seem to be quite focused on latency. Latency is not necessarily something you care about. For coarse grained logistics information, for example, it doesn't really matter if the push notification arrives a few tens or hundreds of milliseconds (or even seconds) later. So if you don't like the latency aspects I am inclined to ask: "What do you need the low latency for?". The explanation on the page itself states the following: Use this pattern when you: * Need to build a common set of client connectivity features for multiple languages or frameworks. * Need to offload cross-cutting client connectivity concerns to infrastructure developers or other more specialized teams. * Need to support cloud or cluster connectivity requirements in a legacy application or an application that is difficult to modify. This pattern may not be suitable: * When network request latency is critical. * When client connectivity features are consumed by a single language. * When connectivity features cannot be generalized and require deeper integration with the client application. If you want to question the usefulness of the pattern, it is best to argue against the use-cases in which it is recommended to be used instead of using a scenario the pattern _explicitly_ states it is not meant for (i.e.: low latency). Now you also had some thoughts on complexity. Regarding what you said: (retries, resiliency, extra logic) it will have to live somewhere. You don't add meaningless complexity for the sake of it after all. How are you going to add another retry policy to a blob you have no control over otherwise? Shifting the burden of networking is also an explicit option listed in the "suitable for" section. You can decide where complexity lives after all. If accidental complexity is your issue I am inclined to ask where you see it here in general. Both the ambassador pattern and your proposed alternatives add overhead in terms of complexity somewhere. I'm struggling to see a clear favorite here. Explicitly regarding your last statement that "[...] the remote service should protect itself against this).": Retries and Monitoring are things the remote service can't do by itself by definition. Even load balancing/shedding might not be solvable by it depending on the situation. Notice that circuit breaking is not the only thing the ambassador is used for. Network related configuration updates (see section "Context and problem") are something that might not be done by the remote service either.