API gateways: what they actually do

A system built from several backend services (an orders service, a payments service, an inventory service) could expose each one directly to consumers — but that forces every consumer to know which specific service owns which endpoint, and it means every cross-cutting concern (auth, rate limiting, logging) has to be implemented separately, in every service, for every language those services happen to be written in. An API gateway sits in front of all of them as one entry point, so consumers see a single, coherent API regardless of how many services actually implement it behind the scenes.

At minimum, a gateway routes each incoming request to whichever backend service actually handles it, based on the path or method — directly building on System Design's load balancing lesson, since routing to a specific service is really "load balancing," just keyed by request shape instead of purely round-robin across identical servers.

Centralizing all of this in one place is powerful, but it also means the gateway itself now sits on the critical path of every request — a misconfigured gateway or a gateway outage can take down access to otherwise-healthy backend services, and every request pays whatever latency the gateway itself adds. This is why gateways are built and operated with the same seriousness as the backend services themselves, often deployed with their own redundancy and careful capacity planning.

A gateway is where several previously-separate lessons' concerns actually meet in one running piece of infrastructure: System Design's load balancing and rate limiting, Auth's token verification, lesson 8's consistent error shapes (often enforced or reformatted at the gateway so every backend service doesn't need to independently implement the exact same error convention), and lesson 9's API contract, all converging on the one component every request actually passes through first.