API Gateways

An API gateway is the entry point between API clients and one or more backend services. For HTTP, it is a reverse proxy with API-aware policies. A client addresses the gateway. The gateway accepts the connection, applies configured policy, selects a backend, and relays the result.

The gateway does not become the backend. It sits on the request path and mediates access to backend capabilities. This position gives it useful context, but it also makes the gateway part of every request's latency and failure path.

Why put a gateway in the path

Without a gateway, each client may need to discover service endpoints and handle their different protocols or failure behavior. Every exposed service also needs its own edge controls. A gateway can present one stable API surface while backend services move, split, or use private addresses.

Routing is the core job. A route can select a backend from the request host, path, method, header, or other application-layer information. The gateway can also terminate TLS, validate credentials, enforce traffic policy, transform messages, cache eligible responses, and emit telemetry.

These features are optional. Start with the smallest policy set that solves a defined boundary problem. Each added policy changes request behavior and creates configuration you must test, deploy, observe, and recover.

Follow one request

A typical request passes through five stages:

1. The gateway accepts a client connection and identifies the matching API and route.
2. It applies admission policy, such as credential validation, request-size limits, or rate limits.
3. It rewrites or preserves protocol information according to the route contract.
4. It connects to the selected backend and relays the request.
5. It applies response policy, records telemetry, and returns the response to the client.

The exact order matters. Authentication after a costly transformation wastes work. Caching before authorization can expose data if the cache key ignores identity. Retrying a non-idempotent request can repeat a state change. Treat policy order as executable behavior.

Separate policy from traffic

Gateway products often separate a management plane from a runtime data plane. You use the management plane to define APIs, routes, credentials, policies, and deployments. The data plane proxies live traffic and emits runtime telemetry.

That separation creates two failure questions. Can existing gateways continue serving when management is unavailable? How does a bad configuration reach the runtime fleet? Review configuration propagation, rollback, regional placement, and capacity before relying on a product's feature list.

Know what belongs at the boundary

Good gateway policies use information available at the boundary and apply consistently across services. Examples include route selection, TLS handling, token validation, coarse traffic limits, protocol translation, request correlation, and common response headers.

Business rules belong near the business data. A gateway may validate a token and reject a missing scope. The backend still needs object-level and function-level authorization because it knows which resource and action the caller may use. OWASP lists broken object authorization and broken function authorization as separate API risks.

Aggregation is a deliberate exception. A gateway can call several backends and combine their results, reducing client round trips. It also couples one client operation to several dependencies. Put domain-heavy composition in a dedicated service when it needs complex logic, long-running work, or independent scaling.

Place it in the wider traffic system

An API gateway can overlap with a reverse proxy, load balancer, ingress gateway, web application firewall, or service-mesh gateway. Product names do not establish the boundary. Required behavior does.

A basic reverse proxy may be enough for TLS termination and routing. A dedicated API gateway fits when you also need API credentials, quotas, transformations, developer-facing publication, or detailed API policy. A service-mesh ingress gateway fits when external traffic must enter the mesh's identity and policy system.

You can run one shared gateway, several domain gateways, a gateway per environment, or a backend for each client type. More centralization improves consistency but increases shared blast radius and coordination. More gateways improve isolation but multiply policy, certificate, capacity, and observability work.

Preserve HTTP meaning

An HTTP gateway is an intermediary, not permission to reinterpret HTTP arbitrarily. Preserve method semantics, status codes, cache directives, validators, content negotiation, and hop-by-hop field rules unless the public API contract explicitly changes them.

Proxying can hide the original client address, host, and protocol from a backend. RFC 7239 defines the Forwarded field for disclosing selected information across trusted proxy hops. Never trust client-supplied forwarding fields by default. Define which proxy removes untrusted values and which hops may append trusted values.

Rate limiting protects capacity and communicates allocation policy. It is not exact accounting. Amazon API Gateway documents its throttles and quotas as best-effort targets. Design clients for 429 Too Many Requests, and define retry guidance without creating a synchronized retry storm.

Operate the whole request path

Measure the gateway and the backend separately. At minimum, track accepted requests, policy rejections, route misses, rate-limit responses, gateway errors, backend errors, latency, payload size, active connections, and saturation.

Propagate a correlation or trace context across the hop. OpenTelemetry models inbound server spans and outbound client spans separately. That split lets you distinguish time spent in gateway policy from time spent waiting for a backend.

Deploy route and policy changes like application code. Validate configuration, test representative requests, stage rollout, compare error and latency signals, and keep a fast rollback path. A syntactically valid route can still send production traffic to the wrong backend.

Limits

A gateway cannot repair an unclear API contract or an unreliable backend. It does not replace service authorization, input validation, capacity planning, or end-to-end tracing. Central policy can reduce duplication, but it can also hide ownership and spread one mistake across many APIs.

Do not add a gateway only because the architecture contains multiple services. Direct access may be clearer when there is one trusted client, one backend, and no shared boundary policy. Add the intermediary when its routing, security, traffic, or lifecycle responsibilities justify its operational cost.