Implementing API Gateway Patterns
1. API Gateway Pattern
| Responsibility | Detail |
|---|---|
| Single Entry Point | Clients hit gateway; gateway routes to services |
| Cross-Cutting | Authn/z, rate limiting, logging, CORS, TLS termination |
| Protocol Bridging | HTTPS in → gRPC out, REST in → events out |
| Tools | Kong, Apigee, AWS API Gateway, Istio, Spring Cloud Gateway, Envoy |
2. Backends for Frontends Pattern
| Aspect | Detail |
|---|---|
| One BFF per UI | Web BFF, iOS BFF, Android BFF |
| Owned by | Frontend team that consumes it |
| Purpose | Tailor API shape to client needs (avoid over/under-fetching) |
| Avoids | One-size-fits-all gateway becoming bottleneck |
BFF Topology
[Web] → [Web BFF] ─┐
[iOS] → [iOS BFF] ─┼→ [Order Svc] [Catalog Svc] [User Svc]
[Android]→ [Android BFF]─┘
3. Gateway Routing Pattern
| Routing Type | Example |
|---|---|
| Path-based | /orders/* → order-service |
| Host-based | api.shop.com vs internal.shop.com |
| Header-based | X-Tenant: acme → acme cluster |
| Weighted | 90% v1, 10% v2 (canary) |
| Geo | Route to nearest region |
4. Gateway Aggregation Pattern
| Aspect | Detail |
|---|---|
| Definition | Gateway calls multiple services and aggregates response |
| Reduces | Client round-trips, especially on mobile |
| Pattern | Parallel calls; merge results; return composite |
| Caveat | Risk of becoming god-gateway; prefer BFF for complex aggregation |
Example: Aggregated Order Detail
CompletableFuture<Order> o = supplyAsync(() -> orderSvc.get(id));
CompletableFuture<Customer> c = supplyAsync(() -> customerSvc.get(custId));
CompletableFuture<Shipment> s = supplyAsync(() -> shippingSvc.get(id));
return CompletableFuture.allOf(o, c, s)
.thenApply(v -> new OrderDetail(o.join(), c.join(), s.join()));5. Gateway Offloading Pattern
| Offloaded Concern | Why at Gateway |
|---|---|
| TLS Termination | Centralizes cert management |
| Authentication | Validates JWT once; passes claims downstream |
| Rate Limiting | Protects all services uniformly |
| Compression / Caching | Reuse across services |
| Request/Response Logging | Centralized audit |
6. Micro Gateway Pattern
| Aspect | Detail |
|---|---|
| Definition | Small, dedicated gateway per service or service group |
| Avoids | Monolithic gateway bottleneck |
| Deployed | Co-located with service or as sidecar |
| Use With | Service mesh; per-team ownership |
7. GraphQL Gateway Pattern
| Aspect | Detail |
|---|---|
| Schema | Unified schema (federation/stitching) |
| Resolvers | Each field resolved by owning service |
| Client Benefit | Single round-trip; ask exactly what you need |
| Tools | Apollo Federation, GraphQL Mesh, Hot Chocolate |
| Watchout | N+1 resolver problem → use DataLoader |
8. API Gateway with Circuit Breaker
| Behavior | Detail |
|---|---|
| Per-Route Breaker | Trip independently per upstream |
| Fallback | Cached response, default value, fail-fast 503 |
| Metrics | Trip counts exposed for alerting |
| Built-In | Spring Cloud Gateway + Resilience4j; Istio outlier detection |
9. Edge Service Pattern
| Aspect | Detail |
|---|---|
| Definition | First service hit at network edge; combines gateway + business logic |
| Capabilities | Authn, routing, request shaping, A/B testing, header injection |
| Examples | Netflix Zuul, Cloudflare Workers, AWS Lambda@Edge |
10. Gateway Rate Limiting Pattern
| Limit Scope | Use Case |
|---|---|
| Per-API Key | Tier-based (Free: 100/min, Pro: 10k/min) |
| Per-IP | Anti-abuse |
| Per-User | Fairness across tenants |
| Per-Endpoint | Protect expensive ops |
| Global | Backstop for total throughput |