Ambassador
A co-located proxy handles connectivity concerns to one specific dependency.
IntermediatePlatform
Similar to a sidecar but scoped to a single outbound dependency: the ambassador handles retries, circuit breaking and protocol translation for calls to that dependency, keeping the main service's code dependency-agnostic.
When to use it
- One legacy or third-party dependency needs special connection handling (retries, protocol shim)
- You want to swap or upgrade that dependency's client logic without touching the main service
Trade-offs
- Only addresses one dependency at a time, unlike a full service mesh
- Yet another small process per instance to keep patched and monitored
Components used
Container ServiceReverse ProxyThird-party Client
How it works
- A co-located proxy handles all connectivity to one specific remote dependency on the application's behalf.
- Retries, timeouts, circuit breaking, TLS and service discovery for that dependency live in the ambassador.
- The application makes a plain local call and remains unaware of the network's complexity.
Used in the wild
- Legacy applications that cannot be modified but must gain modern resilience behaviour.
- Connecting to a database or third-party API through a proxy that manages pooling and credentials.
- Uniform client-side behaviour across services written in different languages.
Good to know
- It is a specialisation of sidecar: a sidecar handles cross-cutting concerns broadly, an ambassador handles outbound connectivity to one dependency.
- Debugging becomes indirect — a failure could be the application, the ambassador or the remote service, and the application's logs show only a local call.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Blue-Green Deployment
Run two full production environments, switch traffic between them.
Canary Release
Send a small slice of traffic to the new version before a full rollout.