A design pattern where a helper service (the "ambassador") runs alongside a client to handle communication with a remote service on its behalf.
In distributed systems, remote calls can be unreliable, slow, or have side effects like timeouts or retries. The ambassador isolates these concerns from your main application logic by handling them externally, but locally.
Use it when your application needs to call external services but you want to offload networking concerns like retries, timeouts, circuit breaking, or monitoring.
You need to know
Local Process: The ambassador runs as a sidecar or local proxy, reducing latency and avoiding changes in your main codebase.
Cross-Cutting Concerns: It handles things like retries, metrics, logging, circuit breaking, and security (e.g., TLS) for outbound calls.
Improves Observability: It helps isolate and monitor external dependencies better, making issues easier to detect and recover from.
Popular technologies
Envoy Proxy – A powerful sidecar proxy commonly used in service mesh setups to implement the ambassador pattern.
Linkerd – Lightweight service mesh that can use ambassadors to manage service-to-service communication.
Istio – Full-featured service mesh that relies on sidecar proxies (e.g., Envoy) to implement ambassador-like responsibilities.
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️