Loading...
Loading...
Single entry point for all client requests
Central entry point handling Routing, Auth, and Rate Limiting.
You already know from the microservices module how one deployable splits into independently owned services with separate data, and from the reverse-proxy module how a single front server can terminate connections and forward by path. Your phone app talks to twenty small services behind the scenes, one for users, one for orders, one for payments, and so on. Without a front door, the app memorizes twenty addresses, repeats the same login check twenty ways, and breaks every time a service moves to a new address. An API gateway, a single server that receives every outside request and forwards it to the right inside service, fixes that by giving the outside world one stable address while the inside stays free to move.
Think of it like the front desk of an apartment building, the one analogy we will use here: visitors only learn one address, and the desk figures out which flat gets the parcel, signs for it, and logs the delivery. In the simulation above, send a burst of requests with the gateway off and watch every client juggle addresses and fail separately, then turn the gateway on and watch the same burst funnel through one door where you can see each request get checked, routed, and logged in one place.
The naive fix is to let every phone call every service directly and copy the login and throttling code into each service. We tried that layout on paper and rejected it because every new rule has to be pasted twenty times and every moved service forces an app update, so correctness rots as the fleet grows. The gateway moves those shared jobs out of the services and into one place.
A request passes through the same four steps in order: prove who you are, check whether you are asking too fast, pick the right service, and write down what happened. The order matters because there is no point routing a stranger, and no point logging after you have already crashed. Watch this order in the diagram below and then in the live traffic above.
Routing means reading the path at the start of the web address, plus optional headers (small labeled extras attached to a request) and the method (the verb like GET for read or POST for create), then looking up which service owns that prefix. Above, try sending /api/users/42 and /api/orders/42 and watch them land on different services even though they entered through the same door, because the table below is all the gateway consults.
The edge case that breaks naive prefix tables is overlapping paths: /api/orders/search versus /api/orders/:id. The gateway must match the most specific rule first, or a search request lands on the single-order handler. In the lab, add a specific rule above the wildcard and watch a previously misrouted request snap to the right service.
Authentication, proving who the caller is, usually arrives as a JWT (a JSON Web Token, a short signed note that says who you are and when it expires, sealed so tampering is detectable). The gateway checks the seal with the matching public key, rejects expired notes, and then stamps the inside request with a plain user id header the services can trust. Services stay simple because they never see passwords or signatures.
The failure mode to respect is a stolen note: anyone holding it can impersonate the user until it expires. That is why gateways keep lifetimes short, often 5 to 15 minutes, and pair the short note with a longer refresh flow handled separately. In the lab, shorten the expiry and watch a replayed request flip from accepted to rejected.
Cross-cutting concerns is a stiff phrase for jobs every service would otherwise repeat: speed limits, browser permission headers, small request reshaping, short-term answer caching, spreading load across copies, and logging. Doing each once at the gateway is cheaper to build and easier to observe, which is why the simulation shows one dashboard for all of them instead of six per service.
Say 100 requests per minute per user. The gateway counts per key and returns a 429 (too many requests) before the services ever wake up. Try a burst above and watch the services stay flat while the gateway absorbs it.
Browsers enforce a rule called CORS (cross-origin resource sharing, meaning a page from one site needs permission to read another site). The gateway adds those permission headers centrally so services never think about browsers.
Renaming a field or stripping an internal id keeps old apps working while services evolve. Cheap for one field, dangerous as a transformation layer, so keep it boring.
Repeat GET reads can be answered from gateway memory for seconds. Do the math: at 90% hits, 2ms cached versus 80ms fresh, the average is 0.9 × 2 + 0.1 × 80 = 9.8ms instead of 80ms.
The gateway picks among healthy copies of one service and emits one timed log line per outside request, which is what makes the latency graph above possible.
A phone asking for a dashboard can trigger three inside calls the gateway joins into one reply. That saves two slow mobile round trips, which at 200ms each is 400ms of waiting removed.
Joining calls at the gateway, sometimes called a backend-for-frontend because one endpoint is shaped for one screen, helps slow phones most. The gateway fires the three inside reads in parallel, waits for all of them, and returns one combined object. The trade is that the gateway now owns failure logic: if recommendations fail, does the whole dashboard fail or ship without that panel. Choose partial success deliberately and say so in the reply.
Open-source gateways, programs you host on your own machines with plugin systems for extra rules, suit teams that already operate servers and want custom logic. You pay in operations work: patching, scaling the desk itself, and surviving its outages.
Managed gateways, services run by a cloud provider that charge per request and connect directly to small functions, suit spiky traffic with nobody on call. You pay per request and give up deep customization, and the desk itself can still throttle you if you misconfigure its own limits.
One door, one set of rules, every service hidden behind it. But a front door that every request passes through is also a chokepoint, meaning extra delay per request and a single place whose failure blocks everything. When one greedy caller floods that door with a hundred times its share, what should the door do so everyone else still gets served?
Try this in the playground
Open a template and build it yourself — then take a quiz.