Loading...
Loading...
Loading...
Single entry point for all client requests
Explore API Gateway below: Single entry point for all client requests.
Central entry point handling Routing, Auth, and Rate Limiting.
Use the controls in the lab above, then read the notes below — they explain what you just tried. Topics: routing · security · aggregation.
Key idea: Single entry point for all client requests
You already know from the microservices module how one deployable splits into independently owned services with separate data. You also know 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 lets every phone call every service directly. It also copies 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. Correctness rots as the fleet grows. The gateway moves those shared jobs out of the services and into one place.
Every request walks the same four steps in order. First prove who you are, then check whether you are asking too fast, then pick the right service, then 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 is how the desk picks a service for each request. It reads 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 it looks 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. 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 proves who the caller is. It 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 and rejects expired notes. Then it 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. The short note pairs with a longer refresh flow handled separately. In the lab, shorten the expiry and watch a replayed request flip from accepted to rejected.
Some jobs repeat in every service. Cross-cutting concerns is the stiff phrase for them: 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. That 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 are programs you host on your own machines with plugin systems for extra rules. They 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 are services run by a cloud provider that charge per request and connect directly to small functions. They suit spiky traffic with nobody on call. You pay per request and give up deep customization. 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.