API Gateway Patterns

The API gateway is a critical piece of infrastructure for many architectures, but it's often implemented poorly.

What an API Gateway Does

Routing: Route requests to the appropriate backend service based on URL, headers, or other criteria.

Composition: Aggregate responses from multiple services into a single response.

Translation: Protocol translation (e.g., REST to gRPC, or v1 to v2 API).

Authentication/Authorization: Centralized auth checking before requests reach backend services.

Rate limiting: Protect backend services from overload.

Caching: Cache responses at the edge to reduce backend load.

Common Gateway Patterns

Pattern 1: Single Gateway

One gateway for all traffic. Simple to set up, single point of failure.

Best for: Smaller organizations, monolithic or few microservices, early-stage startups.

Pros: Simple, single place for auth/caching, easier to reason about.

Cons: Single point of failure, can become bottleneck, less flexible.

Pattern 2: Multiple Gateways by Domain

Different gateways for different domains/services. Each gateway handles its domain's traffic.

Best for: Larger organizations with distinct service domains.

Pros: Separation of concerns, teams can gate their own domains, more flexible.

Cons: More complex, consistent policies harder to maintain, potential for inconsistency.

Pattern 3: Gateway per Team

Each team owns their gateway. Maximum flexibility, minimum coordination.

Best for: Very large organizations with many independent teams.

Pros: Team autonomy, each team chooses their gateway tech, clear ownership.

Cons: Inconsistent policies, duplicate infrastructure, harder cross-cutting concerns.

Pattern 4: Edge + Internal Gateways

Edge gateway handles public-facing traffic and basic auth/rate limiting. Internal gateways handle service-to-service communication.

Best for: Organizations with both public APIs and internal microservices.

Pros: Best of both worlds, public API protection without internal complexity, clear boundary.

Cons: Two sets of infrastructure to maintain, requests may traverse multiple gateways.

Gateway Implementation Considerations

Technology Choices

• NGINX/Traefik: Simple, lightweight, good for basic routing and TLS termination
• Envoy: Highly configurable, built for microservices, observability-first
• Kong: Feature-rich, plugin ecosystem, good for teams getting started with gateways
• AWS API Gateway: Managed service, good for AWS-native organizations, can become expensive at scale
• Cloudflare Gateway: Edge-focused, good for public-facing APIs

Critical Plugins/Middleware

• Authentication: JWT validation, OAuth2, API keys
• Rate limiting: Per-user, per-IP, per-API-key limits
• Request/response transformation: Header manipulation, payload mapping
• Observability: Request ID propagation, latency tracking, error tracking
• Caching: Response caching, conditional requests (ETag, Last-Modified)
• Fault injection: Chaos testing, fallback responses

The Honest Truth

API gateways solve real problems but add operational complexity. Don't add a gateway until you have the problems it solves. Start simple and add complexity as needed.

Published June 1, 2026 · 12 min read