API Gateways

If you are new here: An API gateway is a reverse proxy sitting in front of your backend services. Clients (mobile apps, partner integrations, SPAs) talk to one public hostname; the gateway terminates TLS, authenticates traffic, routes to the right internal service, and applies cross-cutting policies (rate limits, logging, WAF).

Analogy: Think of it as the reception desk of your system: every visitor passes through it before reaching individual teams’ offices.

The Problem

Without a central edge, each service might reimplement TLS, JWT validation, rate limiting, CORS, and request logging. That duplicates bugs, drifts configuration, and makes audits painful. Partners might even get different URLs per team.

In plain terms: an API gateway is the one public front door where you enforce identity, policy, and routing — so microservices can focus on business logic, not on reinventing the internet’s edge.

Tiny example: A mobile app always calls https://api.example.com, while inside AWS the gateway forwards /orders/* to ECS service A and /billing/* to service B — clients never learn internal hostnames.

One front door

Clients use one base URL (e.g. api.example.com). The gateway:

Inside the cluster, services may still talk through a service mesh (sidecars, mTLS between pods). Gateway = edge; mesh = internal corridors. Many teams run both.

Example — path-based routing (conceptual):

Config might look like YAML (simplified; products vary):

routes:
  - path_prefix: /v1/orders
    upstream: order-service:8080
  - path_prefix: /v1/payments
    upstream: payment-service:8080

The mobile app only ever learns api.example.com—not internal hostnames.

Cross-cutting policy in one place

Policies you implement once on the gateway:

Route tables map paths → clusters or serverless functions—ops changes without redeploying every app.

Protocol and shape transformation

Gateways can adapt traffic:

This buys time before rewriting old backends.

Aggregation and BFF

A BFF calls several internal services and returns one response shaped for a mobile screen or web page.

Trade-off: BFFs can become thick—still version them like any API.

Example — BFF response composed from two internal calls:

The app calls once:

GET /mobile/v1/home-dashboard HTTP/1.1
Host: api.example.com

The BFF internally might call GET /catalog/featured and GET /users/me/recommendations, then returns one JSON object shaped for the home screen (fewer round trips on a slow mobile network).

Observability at the edge

Generate or forward trace ids (traceparent, x-request-id) at the gateway so every downstream span shares one trace. Dashboards show end-to-end latency, not just one service.

Trade-offs

Why this matters for you

Treat gateway config as infrastructure code: peer review, version control, load tests. Pair this lesson with Rate Limiting and API Design—the gateway enforces what your API contract promises.