How Things Work

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.

How It Works

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.

A Single Entry Point

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.

Request Routing

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.

Aggregation & BFF

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.

Offloading Cross-Cutting Concerns

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

⬡API Gateway

A single entry point that routes, aggregates, and applies cross-cutting policies in front of many services.

🧭Routing

Matching requests (path/host/header) to backend services, decoupling the public API from internal topology.

🧬Aggregation

Fanning one client request out to several services and merging the results into a single response.

📱Backend-for-Frontend (BFF)

A dedicated gateway per client type (web/mobile) that shapes responses for that UI's exact needs.

📤Offloading

Handling auth, TLS, rate limiting, and caching at the edge so services don't each reimplement them.

⚠️Single Point of Failure

The gateway is critical infrastructure — run it redundantly and keep it thin to avoid becoming a bottleneck.

Gateway config (routing + aggregation + policies)

tsx

1# Gateway routing + aggregation + cross-cutting concerns (YARP / Ocelot style)
2routes:
3  - match: { path: /api/orders/{**catch-all} }
4    cluster: orders-service          # simple proxy route
5    transforms: [ { RequestHeader: X-Forwarded-For } ]
6
7  - match: { path: /api/dashboard }
8    # Backend-for-Frontend: ONE client call → many service calls, merged
9    aggregate:
10      - { service: users,     path: /me }
11      - { service: orders,    path: /me/recent }
12      - { service: recommend, path: /me/feed }
13
14# Cross-cutting concerns handled ONCE, at the edge:
15policies:
16  auth:        { type: jwt, issuer: https://id.example.com }   # offloaded
17  rateLimit:   { perKey: ip, limit: 100, window: 1m }
18  tls:         { terminate: true }                             # offloaded
19  cache:       { paths: [/api/products/*], ttl: 60s }

💡

Why This Matters

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

⚠Letting the gateway become a 'god gateway' full of business logic — keep it thin; logic belongs in services.

⚠Forgetting the gateway is a single point of failure — it must be redundant and horizontally scaled.

⚠Aggregation that does sequential service calls instead of parallel fan-out, adding up the latencies.

⚠One bloated gateway trying to serve web, mobile, and partners — separate BFFs serve each better.

⚠Coupling routing config to internal service details so tightly that refactoring services breaks the public API.

Real-World Use Cases

1The Mobile App Making 12 Calls Per Screen

Scenario

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.

Problem

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.

Solution

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

Scenario

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.

Problem

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.

Solution

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.