Ambassador Design Pattern
Post by: syed hussain in All Application Design Patterns
| Name | Ambassador |
| Type | Application |
| Category | Resiliency |
| Description | The Ambassador design pattern is typically used in microservice architectures, however, the same concepts can be applied to non-microservice architectures. Legacy applications that have limited features may not have the capability to communicate with external applications. Ambassadors are helper services that proxy requests from the Host Application to a Receiver service. Ambassador services typically sit in the same shared “node” as the host application. These services are responsible for monitoring the host machine’s state such as network connectivity, latency, security, and monitoring. Ambassador services can also orchestrate Retry and Circuit Breaker patterns if and when needed. |
| Use Case | Use the Ambassador pattern when an application does not support features required in a high-availability system. |
| Considerations | •Creating an Ambassador service on the host application will increase the overhead of the host application. •The Ambassador service may cause a platform fault itself, impacting the Host application. •When network request latency is critical. A proxy will introduce some overhead, although minimal, and in some cases, this may affect the application. |
| Related | Mediator, Side-car |
| Technologies | Windows Background Service, Node.js, IIS API Application, Azure Function in Docker, Nginx |
| Libraries | Docker, Celery |
| Reference | None |
Simple Reference Architecture
In Microsoft Azure, create a Docker container consisting of an Azure Function or a Background Worker process. Enable The Host Application to proxy queries through the Ambassador Service through RPC or RESTful API Web service calls. On completion of any responses, relay the response back to the Host Application.
Microservices Reference Architecture
Tags: Ambassador Resiliency