API Gateway Pattern
The single front door to a microservice system — routing, response aggregation, the Backend-for-Frontend pattern, and offloading auth, TLS, and rate limiting from every service.
An API gateway sits between clients and your services as a single entry point. It routes requests to the right backend, can aggregate several services into one response (and tailor that per client via BFF), and offloads cross-cutting concerns like authentication, TLS, rate limiting, and caching. The result: clients stay simple, the internal topology stays hidden, and policies live in one place.
An API gateway is the one address all clients hit. Instead of clients knowing about dozens of services (their hosts, ports, and protocols), they talk to the gateway, which routes each request to the right backend. Services can move, split, or scale behind it without clients noticing.
The gateway matches each incoming request (by path, host, header, or method) to a target service and forwards it. This decouples the public API surface from the internal service topology — you can reorganize services freely as long as the gateway's routes stay stable.
A single screen often needs data from several services. Rather than making the client fire five calls, the gateway can fan out, gather the responses, and return one merged payload. A Backend-for-Frontend (BFF) takes this further: a tailored gateway per client type (web, mobile) shaping responses to each UI's needs.
Authentication, TLS termination, rate limiting, caching, request logging, and CORS are handled once at the gateway instead of being reimplemented in every service. Services receive already-authenticated, already-validated requests and focus purely on business logic.
Key Concepts
A single entry point that routes, aggregates, and applies cross-cutting policies in front of many services.
Matching requests (path/host/header) to backend services, decoupling the public API from internal topology.
Fanning one client request out to several services and merging the results into a single response.
A dedicated gateway per client type (web/mobile) that shapes responses for that UI's exact needs.
Handling auth, TLS, rate limiting, and caching at the edge so services don't each reimplement them.
The gateway is critical infrastructure — run it redundantly and keep it thin to avoid becoming a bottleneck.
1# Gateway routing + aggregation + cross-cutting concerns (YARP / Ocelot style)2routes:3 - match: { path: /api/orders/{**catch-all} }4 cluster: orders-service # simple proxy route5 transforms: [ { RequestHeader: X-Forwarded-For } ]67 - match: { path: /api/dashboard }8 # Backend-for-Frontend: ONE client call → many service calls, merged9 aggregate:10 - { service: users, path: /me }11 - { service: orders, path: /me/recent }12 - { service: recommend, path: /me/feed }1314# Cross-cutting concerns handled ONCE, at the edge:15policies:16 auth: { type: jwt, issuer: https://id.example.com } # offloaded17 rateLimit: { perKey: ip, limit: 100, window: 1m }18 tls: { terminate: true } # offloaded19 cache: { paths: [/api/products/*], ttl: 60s }
The API gateway is a near-universal microservices component (YARP, Ocelot, Kong, NGINX, AWS API Gateway, Azure APIM) and a staple of system-design interviews. It's where you centralize edge concerns and decouple clients from service sprawl — but it's also critical infrastructure, so understanding how to keep it highly available and thin matters as much as knowing what it does.
Common Pitfalls
1The Mobile App Making 12 Calls Per Screen
A mobile home screen needs profile, recent orders, recommendations, and notifications. The app fires a dozen separate calls to different services over a flaky cellular network — slow to render and battery-draining.
Pushing service composition onto the client means many round trips over high-latency mobile networks, exposes the internal service map to the client, and couples the app to each service's API.
Introduce a Backend-for-Frontend gateway: the app makes one /home call; the BFF fans out to the services in the fast data-center network, merges and trims the data to exactly what the screen needs, and returns a single tailored response.
Takeaway: Aggregation at a BFF turns many chatty client round trips into one. Composition happens in the fast internal network, and each client gets a response shaped for its needs — fewer calls, less coupling, faster UIs.
2Auth Reimplemented (Inconsistently) in Every Service
Each of 15 services validates JWTs, checks scopes, and enforces rate limits on its own. The implementations drift, one service has a subtle auth bug, and changing the token issuer means editing all 15.
Cross-cutting concerns were duplicated across services, guaranteeing inconsistency and security gaps. Every policy change is a 15-service coordinated deploy, and a single mistake opens a hole.
Centralize authentication, rate limiting, and TLS at the gateway. It validates tokens once and forwards trusted, already-authenticated requests (e.g. with a verified identity header) to services on the internal network. Policy changes happen in one place.
Takeaway: Handle cross-cutting concerns at the gateway, not in every service. Centralizing auth, TLS, and rate limiting eliminates drift, closes security gaps, and makes policy changes a single, consistent deploy.
Join the discussion
Comments
Loading comments...
Cookie preferences
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.