A proxy is exactly what its English meaning suggests — something that stands in for, and acts on behalf of, something else. In networking it is a server that sits between two endpoints and inspects, modifies, or relays traffic between them. The same physical mechanism is used for two completely different purposes, and the words for them get mixed up constantly. A forward proxy stands in for the client — corporate users go through one to reach the public internet, the proxy hiding their identity and applying access policies. A reverse proxy stands in for the server — the public internet sees the proxy, and your real backend services hide behind it. The same code can do both jobs, but the use cases are mirror opposites.

An API gateway is a reverse proxy with a job description: it sits at the edge of your backend, exposes a single, well-known address to clients, and handles the cross-cutting concerns that every API needs — authentication, rate limiting, routing, request transformation, observability. It is not a new category of software; it is what happens when a reverse proxy grows up, learns about your business, and starts making routing decisions based on the URL path, the auth token, and the time of day rather than just the destination IP.

The analogy: a forward proxy is the receptionist at a corporate building who screens employees' outgoing calls and packages. A reverse proxy is the receptionist at a public-facing office who screens visitors before they reach the right person inside. An API gateway is that public receptionist, except they also know your appointment, take your ID, decide which department to send you to, log everything you said, and politely turn you away if you've been visiting too often today.

Every API gateway, no matter the vendor, implements roughly the same pipeline. A request enters at the edge and is processed by a series of plugins or filters, each handling one cross-cutting concern. The pipeline order matters: authentication must come before rate limiting (otherwise an unauthenticated flood can exhaust your rate-limit budget), and rate limiting must come before routing (otherwise abusive traffic still reaches your backends). Most outages I have debugged at the edge layer trace back to a misordering or a missing stage.

Routing is the single most important job an API gateway does. A modern gateway can route on path (/api/v1/orders → order-service), method (GET vs POST), header (X-Tenant-ID, Accept-Version), query string, source IP, geographic region, and percentage rollout (canary deployments). The trick is keeping the routing rules simple enough to reason about. A gateway with 400 route rules and dynamic dispatch logic becomes a hidden monolith. Routes should be declarative, version-controlled, and reviewed.

A gateway can rewrite traffic in flight. Headers: strip internal-only headers, inject correlation IDs, add the verified X-User-Id after auth. Body: rename fields, change formats (e.g. legacy clients sending XML to a JSON backend), version-shim old API shapes onto new ones. Status codes: hide implementation-specific errors behind public-friendly ones. Transformation is powerful and dangerous in equal measure — the gateway is now part of your API contract, and changes there can break clients silently. Use it sparingly and version it.

An API gateway pays for itself in three situations: when you have multiple backend services and don't want every one of them to re-implement auth/rate-limiting/logging; when you have multiple kinds of clients (web, mobile, partner APIs) needing different shapes of the same data; and when you want to enforce consistent policy at the edge before traffic reaches your business logic. In all three, the gateway centralises something that would otherwise be scattered across N services in N inconsistent ways. The cost — an extra hop, an additional component to operate — is real but usually justified by the consolidation it enables.

Backend-for-Frontend (BFF) is a specific gateway pattern worth knowing by name. Instead of one gateway serving every client identically, you run a gateway (or thin service) per client type: one for the web app, one for iOS, one for Android, one for partners. Each BFF aggregates and shapes the data the way its client wants — mobile gets compact responses, web gets richer payloads with embedded resources, partners get a stable versioned API. Each BFF talks to the same downstream microservices but exposes a client-optimised facade. The downside is duplication; the upside is that no single gateway has to make “one shape that works for everyone,” which usually means “a shape that's wrong for everyone.”

The biggest anti-pattern in this whole space: stuffing application logic into the gateway. Custom Lua scripts that call databases, JS plugins that aggregate from five services, response transformations that implement business rules — once you've done that, deployments to your “edge” require coordinated releases of business logic, debugging spans gateway code and service code, and onboarding any new engineer means teaching them where the gateway-vs-service line is — because there isn't one any more. The gateway should do generic things: route, authenticate, rate-limit, transform shape (not semantics), observe. The moment it makes a domain-specific decision, that decision belongs in a service.

These two are often conflated and they shouldn't be. The API gateway sits at the north-south boundary — traffic entering or leaving your system. It is concerned with the contract you expose to the outside world. The service mesh handles east-west traffic — service-to-service communication inside your cluster. It cares about mTLS between services, retry budgets, fine-grained traffic shifting for deployments, and observability of internal calls. They solve different problems and you can run both. A common pattern: API gateway at the cluster ingress, service mesh sidecars on every internal service. The gateway authenticates the user; the mesh ensures every internal hop is mTLS-encrypted and observable.

If you take only two patterns into production from this chapter, take these. Circuit breaker at the gateway: when a downstream service starts erroring or timing out at a high rate, stop forwarding traffic to it for a window. The breaker protects the downstream from being pummelled while it recovers, and it returns fast failures to clients instead of having every request stall on a 30-second timeout. Open / half-open / closed states are standard; the tunable parts are the error threshold, the open duration, and the half-open probe count. Highly available gateway pair: the gateway is by definition a single point that all traffic goes through, so it must not be a single point of failure. Run two or more behind an L4 load balancer or via DNS, in different availability zones, with a tested failover. The cloud-managed options (AWS API Gateway, Cloudflare) handle this for you; the self-hosted ones won't.