Part 3 · The Building Blocks
Reverse Proxy vs API Gateway
Reverse proxy, load balancer and API gateway get used interchangeably — NGINX is called all three. What each one is actually for, where authentication and rate limiting belong, the Backend-for-Frontend pattern, and when a gateway is overkill.
On this page
The Problem
You'll hear three terms used almost interchangeably: reverse proxy, load balancer and API gateway. NGINX is called all three. So is Envoy. Architecture diagrams show one, two or all three boxes.
First, the plain definitions. A proxy is a server that sits in the middle and passes requests from one side to the other. A reverse proxy is a proxy in front of your servers. A load balancer is a server that shares requests between many copies of one service. An API gateway is a reverse proxy for APIs that also checks identity and limits, and routes each request to the right service. An API (application programming interface) is a set of URLs that programs call to get data or do actions.
This confusion matters. If you don't know what each one is for, you might put authentication in five different places, or none. You might add a gateway you don't need, or miss the one feature (like rate limiting, which means refusing clients that send too many requests) that would have prevented an outage.
The Core Idea
Think about a large office building.
- A forward proxy is like an assistant who makes calls on your behalf. The outside world sees the assistant's number, not yours. (It works for the client.)
- A reverse proxy is the building's reception desk. Visitors never walk straight into offices. They talk to reception, which forwards them to the right place, checks that visitors aren't carrying anything dangerous, and hides the internal layout. (It works for the servers.)
- A load balancer is a receptionist whose main job is to spread visitors evenly across several identical offices.
- An API gateway is a security-and-concierge desk for a building full of different companies. It checks your ID badge, makes sure you haven't visited too many times today, sends you to the right company's floor, and logs every visit.
They overlap a lot, and one piece of software can play several roles. But the job is different.
How It Works
Forward proxy vs reverse proxy
- •Employee laptops → corporate proxy → internet
- •Sites see the proxy, not the laptops
- •Internet users → reverse proxy → internal servers
- •Users see the proxy, not the servers
- Forward proxies: corporate web filters, school networks, VPN-like privacy tools.
- Reverse proxies: almost every production website.
What a reverse proxy does
A reverse proxy sits in front of one or more servers and handles common chores so your app doesn't have to:
- TLS termination. TLS is the encryption used by HTTPS. The proxy handles the certificate (the proof of identity for your site) and the encryption (post 3), so your app gets plain requests.
- Compression. Makes responses smaller with Gzip or Brotli (two compression formats), to save bandwidth (the amount of data sent).
- Serving static files. Sends
/static/app.jsstraight from disk, very fast, without touching your app. - Caching. Keeps copies of responses so repeated requests are answered quickly, without asking the app again.
- Request buffering. Absorbs slow clients (someone on a weak mobile connection), so your app servers aren't tied up waiting.
- Security. Hides server IPs and versions, blocks bad requests, limits request sizes, and can add a web application firewall (WAF), which is a filter that blocks known attack patterns.
- Routing.
/blog→ the blog server,/app→ the app server. - Load balancing across several backends.
A typical setup for a Node.js or Python app (NGINX is a popular reverse proxy and web server):
- 1Internet
- 2NGINX on :443TLS · gzip/Brotli · serves /static from disk · buffers slow clients
- 3Node.js on localhost:3000spends its time on business logic
Even with just one app server, a reverse proxy is useful.
Load balancer vs reverse proxy
- A load balancer's main job is spreading traffic across many copies of the same service and removing unhealthy ones.
- A reverse proxy's main job is standing in front of servers and handling HTTP chores. It may or may not balance load.
Most modern L7 load balancers are reverse proxies (NGINX, HAProxy, Envoy, AWS ALB). The difference is in emphasis, not in the software.
What an API gateway does
An API gateway is a reverse proxy specialised for APIs, especially when there are many backend services (microservices). A microservice is a small service that does one job, such as users or payments, and runs on its own. On top of reverse-proxy features, a gateway usually adds:
- Authentication and authorisation. Authentication means checking who you are. Authorisation means checking what you are allowed to do. The gateway validates API keys, JWTs or OAuth tokens once, at the front door. (A JWT is a signed token that carries your identity. OAuth is a standard way to give an app limited access to an account.)
- Rate limiting and quotas. A rate limit caps how fast a client can call you. A quota caps the total use in a period. For example: "Free plan: 100 requests per minute".
- Routing to many services.
/users→ user service,/orders→ order service,/payments→ payment service. - Request and response transformation. Rename fields, convert protocols (for example REST, the common style of HTTP APIs, to gRPC, a faster binary protocol), and combine responses.
- API versioning.
/v1/*→ the old service,/v2/*→ the new one. - Analytics, logging and monitoring per API, per customer, per endpoint.
- A developer portal and API keys for external developers (in commercial gateways).
- 1Mobile app · Web app · Partnersthree kinds of clients, one entry point
- 2API gatewayauthenticate token → check rate limit / quota → route → log
- 3User service
- 4Order service
- 5Payment service
Without a gateway, every service would have to validate tokens, apply rate limits and log requests itself: duplicated code, done inconsistently.
Backend for Frontend (BFF)
Different clients need different data:
- a mobile app on a slow network wants small, combined responses,
- a web dashboard wants lots of detail,
- a smart TV app wants something else again.
The BFF pattern (Backend for Frontend) gives each client type its own small gateway/API layer:
- Mobile app
- Mobile BFFsmall, combined responses
- Servicesuser · order · product
- Web BFFrich, detailed responses
- Web app
Each BFF combines several backend calls into exactly what its client needs. The frontend team often owns its BFF, so they can move fast without changing every backend service.
Service mesh: the internal version
Gateways handle traffic coming into your system (called north-south traffic, like a vertical line from the outside world down to your servers). Inside a large microservices system, services also call each other constantly (east-west traffic, a sideways line between services).
A service mesh (like Istio or Linkerd) is a layer that manages how services talk to each other. It puts a small proxy, a sidecar (a helper program that runs beside the main program), next to every service. These sidecars handle retries, timeouts, encryption (mTLS, where both sides prove their identity with certificates) and metrics (numbers that show how the system behaves) for service-to-service calls. It's the same idea as a reverse proxy, spread across the whole system. We'll revisit this in Part 10.
Popular tools
| Tool | Common role |
|---|---|
| NGINX | Reverse proxy, load balancer, static files; also used as a gateway |
| HAProxy | High-performance load balancer / reverse proxy |
| Envoy | Modern L7 proxy; base of many gateways and service meshes |
| Traefik, Caddy | Reverse proxies with automatic HTTPS and easy container setup |
| Kong, Tyk, Apache APISIX | API gateways, often built on NGINX or Envoy |
| AWS API Gateway, Azure API Management, Google Apigee | Managed API gateways |
Where should logic live?
Put cross-cutting, generic concerns in the gateway:
- authentication (is this token valid?),
- rate limiting,
- routing,
- logging,
- CORS headers (HTTP headers that tell browsers which websites may call your API).
Keep business logic in the services:
- "can this user cancel this order?",
- pricing rules,
- validation specific to a feature.
A gateway full of business rules becomes a bottleneck (a single place that slows everyone down) that every team must change, the opposite of what microservices are meant to achieve.
- +Is this token valid?
- +Rate limits and quotas
- +Routing, versioning (/v1, /v2)
- +Logging, CORS headers
- +Can this user cancel this order?
- +Pricing and discount rules
- +Feature-specific validation
- −Business rules in the gateway make it a bottleneck every team must change
Trade-offs
- An extra hop. Every proxy or gateway adds a little latency (usually a millisecond or two).
- A single point of failure (one part that, if it breaks, stops everything) if it isn't run as several redundant copies.
- Centralised power. A misconfiguration in the gateway can break every API at once.
- The risk of a "smart gateway". Too much logic makes it slow to change and hard to test.
- Cost and complexity. For a single small app, NGINX in front is plenty. A full API gateway product can be overkill.
When not to use an API gateway: a monolith (one single app that holds all the code) with one client, or an internal tool with a few users. A simple reverse proxy covers TLS, compression and routing. Add a gateway when you have multiple services, multiple clients, or external developers who need keys and quotas.
In the Real World
Netflix Zuul. Netflix built Zuul as the front door for all requests from devices to its backend. It handled routing, authentication, monitoring and resilience features, and was open-sourced. It's one of the best-known examples of an API gateway in a large microservices system.
Lyft and Envoy. Envoy (an open-source proxy) was created at Lyft to handle both edge traffic and service-to-service traffic as the company moved to microservices. It was later donated to the Cloud Native Computing Foundation and now powers many gateways and service meshes, including Istio.
SoundCloud and BFF. SoundCloud is often credited with popularising the Backend-for-Frontend idea while moving away from a single large app, giving each client (web, iOS, Android) an API layer tailored to it.
Stripe, GitHub and other public APIs. Public APIs that issue API keys, enforce rate limits per plan and show usage analytics are doing the work of an API gateway, whether it's a commercial product or something built in-house.
Your own deployments. If you've put NGINX in front of a Node.js app, used Traefik with Docker, or deployed to a platform that "just gives you HTTPS", you've already used a reverse proxy.
Interview Questions
Q1What's the difference between a reverse proxy and an API gateway?
A reverse proxy sits in front of servers and handles HTTP chores: TLS, compression, caching, static files, routing. An API gateway is a reverse proxy specialised for APIs across many services, adding authentication, rate limits and quotas, versioning, transformations and per-client analytics.
Q2Why put authentication in the gateway?
So tokens are validated once, consistently, before any service is reached, instead of every team reimplementing it slightly differently. Services still perform authorisation for their own business rules, like “can this user cancel this order?”.
Q3What is the BFF pattern, and when would you use it?
Backend for Frontend gives each client type — mobile, web, TV — its own thin API layer that aggregates backend calls into exactly the shape that client needs. Use it when clients' needs diverge and one generic API forces over-fetching or many round trips.
Q4North-south vs east-west traffic?
North-south is traffic entering or leaving your system from clients, handled by gateways and edge proxies. East-west is service-to-service traffic inside it, often handled by a service mesh with sidecar proxies doing retries, timeouts, mTLS and metrics.
Q5When don't you need an API gateway?
A monolith with one client or a small internal tool. A plain reverse proxy like NGINX covers TLS, compression and routing. Add a gateway when you have many services, many clients, or external developers who need keys and quotas.
Key Takeaways
- A forward proxy acts for clients. A reverse proxy acts for servers: TLS, compression, caching, static files, routing, security.
- A load balancer focuses on spreading traffic across copies of a service. Most L7 load balancers are also reverse proxies.
- An API gateway is a reverse proxy for APIs, adding auth, rate limits, routing to many services, transformations and analytics.
- The BFF pattern gives each client type its own tailored API layer. A service mesh applies proxy ideas to internal traffic.
- Put generic concerns in the gateway and business logic in the services. Keep gateways redundant and simple.
Further Reading
- The System Design Primer on GitHub (section "Reverse proxy (web server)")
- microservices.io by Chris Richardson (the "API Gateway" and "Backends for Frontends" patterns)
- Azure Architecture Center (the "Gateway Routing", "Gateway Offloading" and "Backends for Frontends" patterns)
- Sam Newman's article "Backends For Frontends"
- The official NGINX reverse proxy guide and Envoy documentation
Published by Jainik · Last updated · How these lessons are made
Keep learning
Related series