Working with API Gateways
1. Understanding API Gateway Role
Single entry point in front of backend services that handles cross-cutting concerns and provides a unified, stable interface to clients.
Clients
|
v
+--------------+ +-----------+
| API Gateway |----->| Service A |
| - Auth | +-----------+
| - Routing | +-----------+
| - Rate limit |----->| Service B |
| - Transform | +-----------+
| - Logging | +-----------+
+--------------+----->| Service C |
+-----------+
2. Implementing Request Routing
| Routing Rule | Example |
|---|
| Path-based | /users/* → user-service |
| Host-based | admin.example.com → admin-service |
| Header-based | X-API-Version: 2 → v2 service |
| Weighted (canary) | 5% → new version, 95% → current |
3. Implementing Rate Limiting at Gateway
| Benefit | Detail |
|---|
| Centralized policy | One config covers all services |
| Pre-backend protection | Bad traffic stopped at edge |
| Per-tier enforcement | Free vs paid tier policies |
| Distributed counters | Redis or built-in |
4. Implementing Authentication at Gateway
| Pattern | Detail |
|---|
| JWT validation | Verify signature, expiry, audience |
| OAuth introspection | Check opaque token at IdP |
| API key lookup | Cache key → tenant mapping |
| mTLS | For internal/B2B services |
| Pass identity downstream | Inject X-User-ID, signed JWT |
| Transformation | Use |
|---|
| Add/remove headers | Strip internal headers, add tenant context |
| Path rewriting | /v1/users → /internal/users |
| Body transform | JSON↔XML, field renames (legacy bridges) |
| Query param injection | Add tenant_id from token |
6. Implementing Load Balancing
| Algorithm | Use |
|---|
| Round-robin | Simple uniform distribution |
| Least connections | Long-lived requests |
| Weighted | Heterogeneous instances |
| Health-aware | Skip unhealthy upstreams |
| Zone-aware | Prefer same AZ for latency |
7. Implementing Circuit Breaker Pattern
| State | Behavior |
|---|
| Closed | Requests pass through normally |
| Open | Fail fast (return cached/error) after threshold |
| Half-open | Trial requests; if successful → closed |
| Tools | Resilience4j, Envoy outlier detection, Istio |
8. Implementing Request Aggregation
| Pattern | Use |
|---|
| BFF (Backend for Frontend) | Tailored aggregation per client (web, mobile) |
| GraphQL gateway | Single query → multiple service calls |
| Composed endpoints | Gateway calls 3 services, returns merged DTO |
| Reduces round-trips | Critical for high-latency mobile clients |
9. Caching at API Gateway
| Benefit | Consideration |
|---|
| Reduce backend load | Cache GET responses with Cache-Control |
| Lower latency | Edge cache nearer client |
| Vary by header | Authorization, Accept-Language |
| Invalidation | Purge API, TTL |
10. Monitoring API Gateway
| Metric | Purpose |
|---|
| Requests/sec per route | Traffic distribution |
| Per-upstream latency | Backend health |
| Error rate per consumer | Identify misbehaving clients |
| Rate limit rejections | Capacity planning |
| Auth failures | Security signal |
| Gateway | Notes |
|---|
| Kong | OSS + enterprise; plugin ecosystem |
| AWS API Gateway | Managed; tight Lambda integration |
| Apigee (Google) | Enterprise, analytics-focused |
| Envoy + Istio | Service mesh + gateway |
| Traefik | Container-native, auto-discovery |
| NGINX / OpenResty | High-perf, scriptable |
| Tyk | OSS gateway with developer portal |