Ambassador Pattern
A helper process that handles outbound network communication on behalf of an application, adding retries, routing, security and telemetry without changing it.
A sidecar runs alongside an application and adds capability to it. An ambassador is the sidecar specialisation that owns outbound connections: the application connects to localhost, and the ambassador handles discovery, TLS, retries, circuit breaking, load balancing and telemetry.
Where it earns its place:
Legacy applications that cannot be modified but must participate in a modern network — mTLS, service discovery, distributed tracing — all added without touching the binary.
Polyglot estates, where implementing the same resilience policy correctly in six languages is a recurring source of inconsistency and bugs. One ambassador implementation replaces six libraries.
Database and third-party access, where connection pooling, credential rotation and rate limiting are better centralised than duplicated.
Costs, which are the same as for any sidecar: CPU and memory per workload, an extra network hop of one to two milliseconds, and a second component in every debugging session — "connection refused" becomes a question about the ambassador's configuration rather than the application's.
A service mesh is essentially this pattern applied uniformly with a control plane, which is why the ambient or sidecar-less mesh model exists: to keep the capability while reducing the per-workload overhead.