Architecture
An ambassador pattern architecture diagram with a local proxy sidecar handling authentication header injection, circuit breaking, retry logic, and metrics collection for outbound requests to external third-party APIs. This template models the ambassador pattern where a helper service running alongside the application offloads cross-cutting concerns for external communication. Useful for teams integrating with unreliable third-party services that need resilience wrappers.
Application { # Application Container
n1: circle label:"Outbound Request"
n2: rectangle label:"Application Code"
n3: rectangle label:"Ambassador Proxy"
n4: rectangle label:"Receive Proxied Response"
n5: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="localhost:9000"]
n3.handle(bottom) -> AmbassadorLogic.n6.handle(top) [label="Intercept"]
n4.handle(right) -> n5.handle(left)
}
AmbassadorLogic { # Ambassador Logic
n6: rectangle label:"Add Auth Headers"
n7: rectangle label:"Apply Circuit Breaker"
n8: rectangle label:"Enable Retry Logic"
n9: rectangle label:"Collect Metrics"
n10: diamond label:"Circuit Open?"
n11: rectangle label:"Forward to External Service"
n12: rectangle label:"Return Cached Fallback"
n6.handle(right) -> n7.handle(left) [label="Bearer Token"]
n7.handle(right) -> n10.handle(left)
n10.handle(right) -> n8.handle(left) [label="Closed"]
n10.handle(bottom) -> n12.handle(top) [label="Open"]
n8.handle(right) -> n11.handle(left) [label="With Retry"]
n11.handle(bottom) -> ExternalService.n13.handle(top) [label="HTTPS"]
n12.handle(top) -> Application.n4.handle(bottom) [label="Fallback"]
n11.handle(right) -> n9.handle(left) [label="Latency"]
}
ExternalService { # External API
n13: rectangle label:"Third-Party API"
n14: rectangle label:"Process Request"
n15: rectangle label:"Return Response"
n13.handle(right) -> n14.handle(left)
n14.handle(right) -> n15.handle(left)
n15.handle(top) -> Application.n4.handle(bottom) [label="Response"]
n15.handle(top) -> AmbassadorLogic.n9.handle(bottom) [label="Metrics"]
}
Integrating with external third-party APIs often requires adding authentication headers, retry logic, circuit breaking, and metrics collection—cluttering application code with infrastructure concerns. The ambassador pattern offloads these cross-cutting concerns to a local proxy sidecar, keeping application code focused on business logic.
Embedding resilience logic in application code creates language-specific maintenance burden. API management platforms handle some concerns but add latency. This template shows the ambassador sidecar approach for external API integration.
| Template Name | Ambassador Pattern Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A circuit breaker resilience architecture diagram showing the complete state machine with closed, open, and half-open states, failure threshold tracking, recovery timer, and fallback response strategies for protecting services from cascading failures. This template visualizes the circuit breaker pattern in detail, including how the breaker transitions between states based on success and failure counts. Essential for building fault-tolerant microservices that degrade gracefully under load.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.