Proxies, reverse proxies and API gateways

Step 1 Understand it

The problem it solves. With many services, every would need to know every service's address, and every service would repeat the same login checks, and . That's duplicated, inconsistent work.

New words in this topic (tap one to see what it means)

Watch it happen

AnimationOne front door that checks, limits and routes every request

Read the animation as text

Clients send every request to one address, api.example.com, instead of knowing about every service.
The gateway handles TLS, then checks the token (who is this?)…
…and the rate limit (are they allowed this many requests?).
It routes by path: /orders/… goes to the order service. (Behind it, a load balancer picks one copy of that service.)
It waits for the answer, sends it back, and logs the request and how long it took. Business logic stays in the services, not the gateway.

Picture it

flowchart LR
  C["Clients"] --> G["API gateway<br/>TLS · auth · rate limit · logging"]
  G -->|"/users/..."| US["User service"]
  G -->|"/orders/..."| OS["Order service"]
  G -->|"/payments/..."| PS["Payment service"]

Every goes through one front door. The checks and logs it, then sends it to the right service based on its path.

The idea

Clients talk to one entry point instead of many . That entry point can handle , compress , , check , apply rate limits, and send /orders to the order service and /users to the user service.

How it works, step by step

The client sends every request to one address, for example api.example.com.
The gateway handles TLS, then checks the token (who is this?) and the rate limit (are they allowed this many requests?).
It looks at the path: /orders/… goes to the order service, /users/… to the user service.
It forwards the request, waits for the answer and sends it back, logging the request and how long it took.
Behind it, each service may run several copies, so a (often built into the gateway) picks one.

Analogy

A hotel reception. Guests don't walk into the kitchen or the laundry; reception checks who they are and passes each request to the right department.

Where the analogy breaks

A reception desk with one person is a and a . A gateway must itself be and kept fast, or every request suffers.

Example

or Envoy as a ; a managed API gateway that checks tokens and allows 100 requests per minute per key before anything reaches the services.

Must-know points

Forward proxy: acts for clients (for example, a company's web proxy). Reverse proxy: acts for servers.
Gateway jobs: routing, , rate limiting, TLS, request logging, API .
A load balancer spreads traffic across copies of a service; a gateway decides what's allowed and which service it goes to. Many products do both.
Keep business logic out of the gateway.

Common mistakes

Putting business rules in the gateway, so it slowly becomes a hidden .
Running a single gateway instance: a single point of failure.
Doing heavy work in the gateway that slows down every request.

Step 2 Go further (free, optional)

Optional. The notes above are written to be enough on their own. These free resources give a second explanation and extra practice.

Watch

ByteByteGo: API gateway explained

ByteByteGo · YouTube
Read

The System Design Primer

Donne Martin · GitHub, free

Step 3 Practise

Try each exercise yourself first: on paper, out loud or in code. Then open the answer and compare it with yours.

ExplainSay it in plain words in under a minute, with no notes.

Explain reverse proxy versus forward proxy in two sentences.

Show answer
A forward proxy works for clients: it sits in front of users and sends their requests out to the internet for them, for example a company proxy that filters and logs staff web browsing.
A reverse proxy works for servers: it sits in front of your servers and receives requests from the internet for them, handling TLS, caching and load balancing, and hiding the servers behind it.

DrawSketch the diagram (or class diagram) from memory.

Draw client → gateway → three services, and label what the gateway checks.

Show answer

The checks run in order and stop early: a request without a valid token never costs a rate-limit lookup or reaches a service. Routing is by path, and every request is logged with how long it took.

text

Client
  │ HTTPS
  ▼
API gateway, in order:
  1 TLS ends here
  2 token valid?          no → 401
  3 allowed this call?    no → 403
  4 under the rate limit? no → 429
  5 log it, route by path
  │
  ├─ /users/…    ──► User service
  ├─ /orders/…   ──► Order service
  └─ /payments/… ──► Payment service

ApplyUse it in a real design question and say exactly where it fits.

List what your gateway would do for a mobile banking app.

Show answer
For a mobile banking app, the gateway would:
• End TLS, with modern settings only (the app also pins the certificate).
• Check the on every request (signature, expiry, audience), and that its scopes allow the call: a "read balance" token can't make payments.
• Rate-limit per user, per device and per , strictly on login and one-time-code , to slow down password guessing.
• Route by path: /accounts to the accounts service, /payments to payments, /cards to cards.
• Reject bad requests early: too large, wrong content type, missing required headers (such as an on POST /payments).
• Add a request ID and headers, and write an audit log, with card numbers and personal data masked.
• Handle API versions, and tell very old app versions to upgrade.
• Apply to each backend, and stop calling a failing one for a while (a ).
• Block known bad traffic (a web application firewall, bot detection).
What it would not do: work out balances, check payment limits or run fraud rules. That is business logic, and it belongs in the services.
Trade-offsSay what it costs, when not to use it, and the alternative.

What goes wrong if business logic slowly creeps into the gateway?

Show answer
• It becomes a hidden monolith: every team needs changes in the one shared gateway, so releases up behind it and teams are tied together again, which is what were meant to stop.
• Rules end up split: half a rule in the gateway, half in the service, and nobody can see the whole thing or test it in one place.
• It is hard to test and debug: gateway logic often lives in configuration or plugin scripts, without the tests, reviews and tooling of normal code.
• A bigger blast radius: a bug in the gateway breaks every service at once, not just one.
• Everything gets slower: heavier work in the gateway adds to every single request, and makes the gateway harder to scale.
Keep the gateway to jobs that are the same for every service (TLS, authentication, rate limits, routing, logging), and keep decisions about the business in the services.

Step 4 Interview-ready, then prove it

Your interview answer

About 20 to 40 seconds, said out loud. Practise it until it sounds like you, not like notes.

I'd put an API gateway at to authenticate requests, apply rate limits and route each path to the right microservice, so services don't each re-implement those concerns. It's replicated, so it isn't a single point of failure.

Follow-up questions

Gateway or load balancer?

A load balancer spreads requests across copies of one service. A gateway handles API concerns like auth, limits and routing between different services. Often you use both.

What's the downside of a gateway?

An extra network hop, and a central component that must scale and stay up.

Tick each check when you can do it without notes

A topic is finished when you pass all four checks, not when you finish a video. Be strict: if you needed your notes, it is not ticked yet.

ExplainExplain Say it in plain words in under a minute, with no notes.
DrawDraw Sketch the diagram (or class diagram) from memory.
ApplyApply Use it in a real design question and say exactly where it fits.
Trade-offsTrade-offs Say what it costs, when not to use it, and the alternative.

0 of 4 checks ticked.

Saved in this browser. Back it up or move it to another device.