Reverse Proxy, API Gateway & the Edge

Cross-cutting concerns live once, at the door

As soon as you have more than a couple of services, you face a question: where do the concerns that every request needs (TLS, auth, rate limiting, routing) actually live? The wrong answer is "in every service," because then you reimplement auth twelve times and update it twelve times. The edge tier exists to handle cross-cutting concerns once, in front of everything.

Reverse proxy, then API gateway

The reverse proxy sits in front of your backends and forwards client requests to them. Its jobs are infrastructural: TLS termination, request routing, connection buffering (absorbing slow clients so backends are not tied up), response compression (gzip/brotli), and static asset serving. Nginx and Envoy are the canonical examples. A reverse proxy is content-aware (L7) but does not know about your business or your users.

An API gateway is a reverse proxy that also owns application-edge policy. On top of routing and TLS it does: authentication and authorization (validate the JWT or session, reject anonymous calls before they reach a service), rate limiting and quotas (per-API-key token buckets), request and response transformation (rewrite headers, translate protocols), and sometimes aggregation (fan one client call out to several services and merge). Kong, AWS API Gateway, Apigee, and Envoy-plus-control-plane are typical. The value is that a request is authenticated, rate-limited, and validated once at the door, so internal services can trust it and stay focused on business logic.

Interview nuance: The classic follow-up is "what belongs at the gateway versus in the service." The line: put cross-cutting, request-shaped concerns at the gateway (authn, coarse authz, rate limits, TLS, routing, WAF). Keep business concerns in the service (domain validation, fine-grained authorization like "can this user edit this specific document," pricing rules). Auth token validation is edge work; deciding what this user may do to this resource is service work.

BFFs and the mesh

The BFF (backend-for-frontend) pattern is a gateway variant: instead of one general gateway, you run a thin per-client gateway. The web app talks to a web BFF, the mobile app to a mobile BFF. Each BFF aggregates and shapes exactly the payload its client wants, so the mobile client is not forced to over-fetch a web-sized response. BFFs prevent one generic API from being pulled in incompatible directions by different clients.

For internal, service-to-service concerns, a service mesh (Istio, Linkerd) is often the better tool than the gateway. Each service gets a sidecar proxy (Envoy) that handles mTLS between services, retries, timeouts, circuit breaking, and traffic-shifting, controlled centrally without changing app code. Mental model: the gateway is north-south (client to system), the mesh is east-west (service to service). Add a WAF and DDoS protection at the very edge, in front of the gateway, to filter malicious traffic before it costs you anything.

The failure mode to avoid: the gateway becoming a logic monolith. It is tempting to keep adding "just one more" business rule to the gateway until it holds pricing logic, feature flags, and per-endpoint special cases, at which point it is a distributed monolith that every team must coordinate on and a single bottleneck all traffic squeezes through. Keep the gateway thin and generic; push business logic down into services.

Internet
  |
[ WAF / DDoS ]            <- filter junk before it costs you
  |
[ API Gateway ]           <- TLS, authn, rate limit, routing (north-south)
  |     |     |
 svcA  svcB  svcC         <- business logic + fine-grained authz
   \____|____/
    service mesh sidecars <- mTLS, retries, timeouts (east-west)

Recap: Push TLS, authn, rate limiting, and routing to a thin API gateway (north-south), handle service-to-service mTLS and retries in a mesh (east-west), use BFFs to shape per-client payloads, front it all with a WAF, and never let the gateway swell into a business-logic monolith.