API Gateway

Definition

All external traffic enters through one component that authenticates, authorises, rate limits, routes, and often transforms. Backend services then trust the gateway's assertion of identity and implement only their own logic.

What genuinely belongs there

• TLS termination and certificate management.
• Authentication, and coarse authorisation. Fine-grained authorisation belongs in the service that owns the resource, because only it knows the rules.
• Rate limiting and quota enforcement per client or tenant.
• Routing, canary splitting, and version routing.
• Request and response logging with a correlation ID injected at the edge.

What does not

Business logic. Data aggregation across services with domain rules in it. Per-consumer response shaping — that is a backend-for-frontend concern, and putting it in the shared gateway creates a component every team must change and none owns.

Industry example

Netflix's edge gateway is instructive for what it was used for beyond routing: it became the place to implement dynamic, operator-controlled behaviour at the edge — shifting traffic between regions, shedding load selectively, running canaries, applying per-device rules, and injecting faults deliberately to test resilience.

That reframes the gateway from plumbing to a control point. During a regional problem, the ability to change routing and shed non-essential traffic at the edge, without deploying anything, is one of the most valuable operational levers an organisation can have.

The cost is equally clear: the gateway becomes the most critical component in the system. It must be more available than anything behind it, its configuration changes are as dangerous as code deployments and need the same review and rollback, and a bad rule there is a total outage rather than a partial one.

Failure scenarios

• The gateway as a distributed monolith. Every team needs a change in it to ship anything, so a shared component becomes the release bottleneck for the whole organisation.
• Business logic accumulating until nobody can reason about request behaviour without reading gateway configuration.
• A single shared instance across tenants, so one tenant's traffic spike degrades everyone.
• Authorisation done only at the edge, so any service reachable internally is unprotected — which is the assumption zero-trust architectures exist to remove.
• Configuration deployed without staging. A regex change routes 100% of traffic to the wrong backend in one second.

Trade-offs

You gain one place to implement cross-cutting concerns, consistent policy, and a powerful operational lever. You pay with a critical shared dependency, an extra network hop, and an organisational coupling point that requires deliberate governance — usually self-service configuration owned by each team, validated automatically, rather than a queue at a platform team's door.

Interview question

"Which responsibilities would you refuse to put in an API gateway, and where would you put them instead?"