# Ambassador Pattern

The Ambassador Pattern is a design pattern used in distributed systems where a helper service sends network requests on behalf of a consumer service or application. It acts as an out-of-process proxy that is co-located with the client.

## 1. The Core Concept

In a microservices architecture, services often need to make network calls to other services. These calls require handling complex networking tasks like:
*   Service Discovery
*   Retries and Timeouts
*   Circuit Breaking
*   Authentication/Security (mTLS)
*   Monitoring and Logging

Instead of implementing this logic inside the application code (which bloats the code and is language-specific), you offload it to a separate container (the Ambassador) running on the same host/pod.

*   **Analogy:** An ambassador represents a country in a foreign land. The country (Application) doesn't need to know the local dialect or customs; it just talks to the Ambassador, who handles the communication with the foreign entity (External Service).

## 2. How it Works

1.  **Application:** The main service wants to call `Service B`. Instead of calling `Service B` directly, it calls `localhost` on a specific port.
2.  **Ambassador:** The ambassador process (running on `localhost`) intercepts the call.
3.  **Processing:** The ambassador adds headers, handles encryption, checks circuit breakers, and performs service discovery.
4.  **Forwarding:** The ambassador forwards the request to the actual `Service B` over the network.

## 3. Benefits

*   **Language Agnostic:** Since the ambassador is a separate process, you can write your app in Python, Go, or Java, and use the same ambassador (e.g., Envoy) for all of them.
*   **Standardization:** Networking policies (retries, security) are defined in one place (the ambassador config) rather than scattered across application code.
*   **Simplification:** The application developer focuses on business logic, not networking infrastructure.

## 4. Sidecar vs. Ambassador vs. Adapter

These are all variations of the multi-container pod pattern, but they differ in intent.

*   **Sidecar:** The generic term. A helper container that enhances the main container (e.g., log shipper, config reloader).
*   **Ambassador:** A sidecar that handles **outbound** traffic. It acts as a proxy for the application to talk to the outside world (e.g., Service Discovery, Circuit Breaking).
*   **Adapter:** A sidecar that handles **inbound** traffic or data. It presents a standardized interface to the outside world (e.g., normalizing logs from different apps into a common format for monitoring).

## 5. Use Cases

*   **Legacy Applications:** Adding modern features like mTLS or tracing to a legacy app without modifying its source code.
*   **Service Mesh:** Tools like Istio and Linkerd essentially implement the Ambassador pattern at scale, injecting an Envoy proxy (ambassador) into every pod.

[[programming/microservices-architecture]]
[[programming/service-mesh]]
[[programming/cloud-native-concepts]]
[[programming/design-patterns]]