Problem
Clients need different data shapes. Direct service calls create chatty interfaces. Cross-cutting concerns duplicated.
architecture-descriptionestablished · medium operational burden
API Gateway Patterns
Also known as: gateway-patterns, backend-for-frontend, edge-patterns
Intent
Common patterns for API Gateway usage: BFF, aggregation, protocol translation, security enforcement.
Forces
- •Mobile needs different data than web
- •Multiple services called per screen
- •Auth, rate limiting, logging needed everywhere
- •Protocol diversity: REST, gRPC, GraphQL, SOAP
Solution
✓ When to Use
- •Multiple client types with different needs
- •Cross-cutting concerns centralized
- •Protocol translation required
✗ When Not to Use
- •Single client, simple services
- •Team not ready for gateway ownership
- •Ultra-low latency path (extra hop)
Pros
- +Client simplification: one call, tailored response
- +Security centralization: one place for auth/WAF
- +Observability: all traffic visible
- +Decoupling: services change, gateway adapts
Cons
- −Gateway becomes bottleneck (scale horizontally)
- −Logic creep: business logic leaks in
- −Single point of failure (HA required)
- −Team friction: who owns gateway?
Cost Profile
Infrastructure
Medium — managed (Kong, AWS) or self-hosted (Envoy)
Operational
Medium — config, certs, scaling, routing rules
Cognitive
Low — well-understood patterns
Failure Modes
Gateway down → all clients down
Aggregation timeout → partial responses
Routing rule error → traffic to wrong version
Auth misconfig → bypass or false reject
Real-World Examples
Alternatives
- direct-service-calls
- graphql-federation
- service-mesh
- bff
Related Patterns
- api-gateway
- bff
- graphql-federation
- service-mesh
- canary-deployment
Competency Domains
distribution communicationsecurity compliancereliability opsdeploymenteconomics evolution