The Gateway: One Front Door
A dedicated look at the API gateway: the cross-cutting jobs it does at the front door, how it relates to reverse proxies and load balancers, and where rate limiting fits.
A deep look at the gateway, the third building block from the request-path overview. The cross-cutting jobs it does once for everyone (authentication, routing, TLS, rate limiting), how a gateway relates to a reverse proxy and a load balancer (they are one overlapping family), the difference between a forward and a reverse proxy, and where rate limiting fits. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
The request-path overview met DNS, the load balancer, and the gateway (how a request finds a server). DNS and the load balancer got their own pieces. Here is the gateway, and the tangle of names that surrounds it.
Picture the front desk of a large office building. Everyone entering goes through it. The desk checks your ID, turns you away if you are not allowed in, and points you to the right floor. Every department upstairs could hire its own guard, but it is simpler and safer to do it once, at the door, for everyone.
A gateway is that front desk for your system. Every request passes through it before reaching any service, and it handles the jobs that every service would otherwise have to repeat.
What it does at the door
The everyday version: one desk, many checks, done once. In a system the gateway does the cross-cutting jobs, the ones every service needs but none should own:
- Authentication: checking who you are, so services can trust the request.
- Routing: sending each request to the service that should answer it.
- TLS termination: ending the encrypted connection at the door, so services behind it can speak plainly on the trusted internal network.
- Rate limiting: turning away callers who come too often (more on this below).
- Aggregation: sometimes gathering answers from a few services into one reply.
Doing all of this in one place keeps every service behind it simpler and consistent. The visualizer shows a request passing the checks, and one caller getting turned away.
One front desk checks who you are, turns you away if you are coming too often, and routes you to the right service. Every service behind it stays simpler.
Gateway, reverse proxy, load balancer: one family
Here is where the names get confusing, so let us untangle them. They overlap on purpose.
A reverse proxy is the general idea: a server that sits in front of your real servers and forwards requests to them, so the outside world talks to the proxy, not the servers directly. A gateway is a reverse proxy that also does the front-desk jobs above. A layer 7 load balancer (from the load balancer piece) is a reverse proxy that also spreads load. So they are not three unrelated things; they are one family, a server in front that forwards, wearing different hats.
So why the different names, if it is one box? Because a name here describes the job, not the machine. A van is a van, but you call it an ambulance, a delivery truck, or a food truck depending on what it is fitted out to do. Same here: "reverse proxy" is the plain van (something in front that forwards), "gateway" is that van doing the front-desk job, and "load balancer" is it spreading load. You reach for whichever word names the job you mean. The words also come from different tools and eras (web servers called it a reverse proxy, networking gear a load balancer, the microservices world an API gateway), which is why they pile up, and sometimes they really are separate boxes, so the distinct names earn their keep.
The opposite of a reverse proxy is a forward proxy, and the easiest way to feel the difference is a hotel. Out front are two people who both stand between guests and the outside world, but they work for opposite sides. The concierge works for the guests: a guest asks for theater tickets, and the concierge goes out into the city and gets them, so the ticket seller only ever deals with the concierge, never the guest. The front desk works for the hotel: anyone from outside who wants to reach a guest goes through the desk, which decides whether to put them through, so outsiders only ever deal with the desk, never the rooms.
A forward proxy is the concierge. It sits in front of the clients and goes out to the world on their behalf, so the outside sees the proxy, not you (a company might route all staff web traffic through one, to filter or log it). A reverse proxy is the front desk. It sits in front of the servers and takes the outside world's requests for them, so callers see the proxy, not the servers. Same middleman-at-the- door idea, opposite side.
A reverse proxy is the hotel front desk: outsiders go through it to reach the servers, which stay hidden. A gateway and a layer 7 load balancer are both reverse proxies.
Where rate limiting fits
One of the gateway's jobs deserves its own attention: rate limiting, capping how often a caller can hit you so a single client, or a runaway bot, cannot flood the system and starve everyone else. The gateway is the natural place to enforce it, because every request already passes through.
How to actually count requests fairly and cheaply across many machines is a rich topic on its own, token buckets, sliding windows, shared counters, so it gets its own piece later in the series. For now, the point is where it lives: at the front door, done once.
Where this goes
That is the gateway: one front door that authenticates, routes, ends encryption, and limits, so the services behind it stay simple. And it is one member of the reverse-proxy family, alongside the layer 7 load balancer. With DNS, the load balancer, and the gateway all covered in depth, the request has reached your servers. Next we make them fast: caching and CDNs.
