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.
Client { # Client Application
n1: circle label:"Incoming Request"
n2: rectangle label:"Load Balancer"
n3: rectangle label:"Receive API Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Gateway.n5.handle(top) [label="Route Request"]
n3.handle(right) -> n4.handle(left)
}
Gateway { # API Gateway
n5: rectangle label:"Authenticate JWT Token"
n6: diamond label:"Token Valid?"
n7: rectangle label:"Apply Rate Limiting"
n8: rectangle label:"Return 401 Unauthorized"
n9: diamond label:"Rate Limit OK?"
n10: rectangle label:"Route to Microservice"
n11: rectangle label:"Return 429 Throttled"
n12: rectangle label:"Aggregate Responses"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Yes"]
n6.handle(bottom) -> n8.handle(top) [label="No"]
n7.handle(right) -> n9.handle(left)
n8.handle(top) -> Client.n3.handle(bottom) [label="401"]
n9.handle(right) -> n10.handle(left) [label="Yes"]
n9.handle(bottom) -> n11.handle(top) [label="No"]
n10.handle(bottom) -> Services.n13.handle(top) [label="Forward"]
n11.handle(top) -> Client.n3.handle(bottom) [label="429"]
n12.handle(top) -> Client.n3.handle(bottom) [label="Response"]
}
Services { # Microservices Cluster
n13: rectangle label:"Service Discovery Lookup"
n14: rectangle label:"User Service"
n15: rectangle label:"Order Service"
n16: rectangle label:"Inventory Service"
n17: rectangle label:"Compose Response"
n13.handle(right) -> n14.handle(left) [label="Users"]
n13.handle(bottom) -> n15.handle(top) [label="Orders"]
n14.handle(right) -> n17.handle(left)
n15.handle(right) -> n16.handle(left) [label="Check Stock"]
n16.handle(right) -> n17.handle(left)
n17.handle(top) -> Gateway.n12.handle(bottom) [label="Aggregated"]
}
Without a centralized API gateway, every microservice must independently handle authentication, rate limiting, and request routing—leading to duplicated logic, inconsistent security policies, and operational complexity. An API gateway provides a single entry point that enforces cross-cutting concerns before requests reach backend services, reducing attack surface and simplifying client integration.
Building authentication and rate limiting into each service leads to inconsistency and maintenance burden. Commercial API gateways like Kong or Apigee cost $10K-100K+/year. This FlowZap template helps teams visualize their gateway architecture before implementation.
| Template Name | Microservices API Gateway Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
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 service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.
Architecture
A Backend-for-Frontend architecture diagram with separate BFF layers for web and mobile clients, each optimizing API responses for their specific platform while sharing common backend microservices. This template shows how to avoid one-size-fits-all APIs by tailoring data aggregation and payload optimization per client type. Recommended for teams serving multiple frontend platforms from a shared microservices backend.
Architecture
An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.
Architecture
A serverless API backend architecture diagram with API Gateway, Lambda authorizer functions, business logic functions, and managed cloud services including DynamoDB, S3, SQS, and SNS for a fully managed, auto-scaling backend. This template models the serverless-first approach where infrastructure management is eliminated entirely, with pay-per-invocation pricing and automatic scaling to zero. Essential for startups and teams building cost-efficient, event-driven API backends.
Architecture
A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.