We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
When you travel abroad and need to interact with a foreign government, you don't navigate their bureaucracy directly. You go to your country's embassy. The ambassador handles the protocols, translations, and paperwork on your behalf. You speak your language, follow your country's processes, and the embassy translates that into whatever the foreign system requires.
The Ambassador container pattern does the same thing for your application's outbound connections. Your app connects to localhost:6379 thinking it's talking to a local instance. The ambassador container intercepts that connection, manages a connection pool to the actual Redis cluster, handles authentication, retries on failure, and routes to the right shard. Your app stays simple. The ambassador handles the complexity of the external world.
This is a specialization of the Sidecar pattern, specifically for managing outbound connectivity to external services. The distinction matters: while a general sidecar can handle anything (logging, metrics, proxying), an ambassador specifically owns the outbound connection problem.
| What the Ambassador Handles | What the App Sees |
|---|---|
| Connection pooling to a database cluster | A single localhost connection |
| TLS termination and certificate management | Plain-text connection to localhost |
| and routing to healthy instances | A fixed localhost:port endpoint |
| Retries with backoff when the external service fails | A reliable connection that mostly works |
| Protocol translation (e.g., Cluster protocol) | Standard Redis commands |
| Read/write splitting across primary and replicas | One connection string |
Common ambassador implementations:
Redis ambassador: twemproxy or a custom proxy running as a sidecar. Handles Redis Cluster protocol, CRC16-based hash slot routing, MOVED/ASK redirections, and failover. The app uses a standard Redis client against localhost. At Twitter, twemproxy ran as an ambassador for years, managing connections to a 30+ shard Redis Cluster. Application code used simple GET/SET commands against localhost.
Database ambassador: PgBouncer or ProxySQL running as a sidecar, pooling connections to a remote database cluster. PgBouncer reduces 500 application connections (one per pod) to 20 actual database connections through transaction-level pooling. The app connects to localhost:5432 and writes standard .
External API ambassador: A proxy that handles OAuth token refresh, , and retries for a third-party API. The app makes simple HTTP calls to localhost:8080/api/whatever. The ambassador adds the auth header, respects rate limits, and retries transient failures with exponential backoff.