API Gateways

Every request to your API has to start somewhere. In a monolith, that's simple—one application, one entry point. But microservices shatter this simplicity. Suddenly you have dozens of services, each with its own address, its own authentication requirements, its own quirks.

Without a gateway, every client becomes an expert on your internal architecture—and that expertise becomes a liability the moment you change anything.

An API gateway fixes this. It's the single front door that clients talk to, while behind it, the chaos of microservices can evolve freely.

What a Gateway Actually Does

Think of an API gateway as three things at once:

A bouncer who checks credentials before anyone gets in. Authentication happens once, at the door, not at every service inside.

A translator who speaks whatever language clients prefer—REST, GraphQL, WebSocket—and converts it to whatever your services actually use.

A traffic cop who knows where everything lives and routes requests to the right place, even as services scale up, scale down, or move entirely.

This isn't just convenience. It's the difference between clients that break every time you refactor and clients that don't even notice.

Authentication at the Edge

Every service needs to know who's calling. Without a gateway, every service implements its own authentication—validating JWTs, checking API keys, handling OAuth flows. The same logic, duplicated everywhere, with inevitable inconsistencies.

The gateway centralizes this. It validates tokens once, verifies permissions once, and passes the authenticated identity downstream. Backend services receive a header saying "this is user X with permissions Y" and trust it, because the request came through the gateway.

This works for everything from simple API keys to complex OAuth 2.0 flows to mutual TLS with client certificates. The complexity lives in one place.

Rate Limiting: Protecting Your Services from Your Users

Your backend services have limits. They can handle a thousand requests per second, not a million. Without protection, one misbehaving client—or one attacker—can bring everything down.

Rate limiting at the gateway enforces boundaries:

• Per-client limits prevent any single caller from monopolizing resources
• Burst allowances handle legitimate traffic spikes without triggering limits unfairly
• Tiered access gives paying customers more capacity than free users
• Graceful degradation returns 429 (Too Many Requests) rather than letting services crash

The gateway tracks usage, enforces limits, and protects your infrastructure from both accidents and attacks.

Request Aggregation: One Call Instead of Ten

A mobile app needs user profile, recent orders, and recommended products. That's three services. Without a gateway, the app makes three requests, waits for three responses, handles three potential failures.

With request aggregation, the gateway exposes one endpoint that:

1. Receives the single request from the client
2. Fans out to all three services in parallel
3. Combines the responses into one payload
4. Returns everything in a single response

The client's code gets simpler. Latency drops because requests happen in parallel instead of sequentially. And the mobile app doesn't need to know—or care—that three services were involved.

Protocol Translation

Your clients speak REST. Your high-performance internal services speak gRPC. Your real-time features use WebSocket.

The gateway translates. Clients use the protocol that's convenient for them. Services use the protocol that's efficient for them. Nobody compromises.

This also provides insulation. When you migrate a service from REST to gRPC for performance, clients don't change at all. The gateway absorbs the translation.

Caching: Don't Compute What You Can Remember

Some responses don't change often. Product catalogs, configuration data, public content—hitting the backend for every request wastes resources and adds latency.

Gateway caching stores responses and serves them directly:

• HTTP caching respects Cache-Control headers and ETags
• Custom policies cache specific endpoints for specific durations
• Invalidation clears stale data when backends signal changes

A well-configured cache can reduce backend load by orders of magnitude while cutting response times dramatically.

Resilience: When Backends Fail

Backend services fail. Networks partition. Databases slow down. Without protection, these failures cascade—one struggling service brings down everything that depends on it.

Gateways implement resilience patterns:

Circuit breakers detect failing services and stop sending them traffic, giving them time to recover instead of piling on more requests.

Timeouts prevent indefinite waits. If a service doesn't respond in 5 seconds, the gateway gives up rather than holding connections open forever.

Retries with backoff handle transient failures automatically, trying again after brief delays.

Fallback responses provide degraded functionality—cached data, default values, or helpful error messages—when backends are completely unavailable.

Service Discovery: Finding Services That Move

In dynamic environments, services don't have fixed addresses. Containers start and stop. Instances scale up and down. The service that lived at 10.0.0.5 yesterday might be at 10.0.0.47 today.

Gateways integrate with service discovery:

• They query registries (Consul, Kubernetes, etcd) to find current service locations
• They health-check instances and route only to healthy ones
• They load-balance across available instances
• They adapt automatically as the topology changes

Clients call stable gateway endpoints. The gateway figures out where services actually live.

Observability: Seeing Everything

Because all traffic flows through the gateway, it sees everything. This visibility is invaluable:

Request logging records every call—who made it, what they requested, how long it took, whether it succeeded.

Metrics track request rates, latencies, error rates, and resource usage across all endpoints.

Distributed tracing propagates trace IDs to backends, enabling end-to-end request tracking across services.

Analytics aggregate patterns—which endpoints are popular, which clients are most active, where errors cluster.

This isn't just operational data. It's business intelligence about how your API is actually used.

Gateway vs. Service Mesh

Both gateways and service meshes manage traffic. The difference is direction:

Gateways handle north-south traffic—requests coming from outside (clients) to inside (services). They're the external API boundary.

Service meshes handle east-west traffic—requests between internal services. They manage the internal communication fabric.

Many organizations use both. The gateway manages the public API. The service mesh manages inter-service communication. They complement rather than compete.

Some tools blur this line—service meshes adding ingress capabilities, gateways routing internal traffic—but the core distinction remains useful.

GraphQL at the Gateway

GraphQL introduces unique gateway patterns:

Schema stitching combines schemas from multiple backend services into one unified API. Clients see one GraphQL endpoint; the gateway federates queries across services.

Query planning optimizes execution, determining which services to call and in what order.

Batching prevents N+1 problems by combining multiple backend requests into efficient batches.

GraphQL gateways provide powerful aggregation but add complexity in schema management and query optimization.

Security: The Most Dangerous Position

The gateway sees all traffic. It has credentials to call all services. It's trusted by clients and backends alike.

This position is powerful—and dangerous. A compromised gateway compromises everything behind it.

Security must be paranoid:

• DDoS protection prevents overwhelming the gateway itself
• Input validation blocks malformed or malicious requests before they reach backends
• TLS termination handles encryption (but means the gateway sees plaintext)
• WAF integration detects and blocks application-level attacks
• Minimal privileges limit what the gateway can access to only what's necessary

The gateway is your most security-critical component. Treat it that way.

Choosing a Gateway

Kong is open-source, plugin-extensible, built on NGINX. Good for self-hosted deployments with custom requirements.

Amazon API Gateway is fully managed on AWS with Lambda integration. Good for serverless architectures.

Azure API Management provides comprehensive lifecycle management. Good for Azure-centric organizations.

Google Cloud Apigee offers enterprise features with advanced analytics. Good for large-scale API programs.

Envoy is a high-performance proxy often used as a gateway foundation. Good for custom implementations requiring fine control.

The choice depends on where you deploy, what features you need, and whether you prefer managed services or self-hosted control.