ADevGuide 
These components can all sit in front of an application and forward HTTP traffic, so teams often use the names interchangeably. That is a costly shortcut: one focuses on healthy-instance distribution, one on client-to-upstream protocol handling, and one on API policy for consumers.
This backend-interview guide separates their primary responsibilities and shows why a production architecture often uses more than one. It follows CORS in the Backend Developer Interview Guide. For a deep dive on gateway alone, see API Gateway Explained.
Table of Contents
Open Table of Contents
The Short Answer
A reverse proxy accepts a client connection and forwards it to an upstream server. Its core concerns are TLS termination, HTTP protocol handling, connection pooling, buffering, compression, caching, and header rewriting. A load balancer chooses a healthy instance from a pool of interchangeable targets. Its core concerns are health checks, capacity, and traffic distribution. An API gateway presents a governed API boundary: it routes APIs and applies consumer-facing policy such as authentication, rate limiting, request validation, and usage observability.
These are roles, not mutually exclusive products. NGINX or Envoy can be a reverse proxy and load balancer; a gateway product can also proxy and balance traffic. In an interview, define the primary responsibility instead of declaring that any product belongs to exactly one category.
Request Flow
flowchart TD
A[Client] --> B[API gateway]
B --> C[Authenticate, rate limit, route API]
C --> D[Service load balancer]
D --> E{Healthy instance}
E --> F[Orders service instance 1]
E --> G[Orders service instance 2]
A --> H[Reverse proxy]
H --> I[TLS, headers, connection handling]
I --> D
classDef flow fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#000000;
class A,B,C,D,E,F,G,H,I flow;The diagram shows two valid paths, not a mandatory stack. A simple application may use only a reverse proxy that also balances instances. A multi-service public API may use a gateway at the edge and a separate load balancer per service. Do not put domain business rules in either layer; services remain the source of truth for orders, permissions, and transactions.
Reverse Proxy
Use a reverse proxy when the client should reach a stable public endpoint while infrastructure behind it can change. It hides internal addresses, terminates TLS, forwards trusted headers, and handles HTTP concerns once rather than in every application. Read how reverse proxies work for the deeper foundation.
Its trade-off is another operational hop. Incorrect forwarded-host or client-IP handling can break redirects, audit logs, or IP-based controls. It may load-balance, but that is an additional capability rather than its defining purpose.
Load Balancer
Use a load balancer when several instances can serve equivalent traffic. It removes unhealthy targets and chooses a destination with a policy such as round robin, least connections, or weighted routing. It can operate at Layer 4 for TCP/UDP or Layer 7 for HTTP-aware rules.
Load balancing is about capacity and availability, not API product management. It cannot replace service authorization just because an L7 product can inspect a path. For the scaling context, review load balancing.
API Gateway
Use an API gateway when many API consumers or services need a consistent public contract. Strong gateway responsibilities include authentication token verification, coarse authorization, route/version policy, per-consumer rate limiting, request-size limits, CORS policy, and API telemetry. It can aggregate simple responses, but orchestrating domain workflows there turns the gateway into a fragile central monolith.
Gateways simplify clients but add latency, cost, and an important availability dependency. Deploy them redundantly and keep their configuration reviewable. See API Gateway Explained for the design details.
When Components Overlap
The same tool can expose all three capabilities, but overlapping features do not erase architectural intent. Ask: “Am I terminating a connection? choosing among copies of one service? or enforcing an API contract across consumers?” One answer may justify one deployment; different answers may justify layered components.
For example, an internet-facing gateway authenticates a mobile client and routes /orders. A service-level balancer selects one healthy orders replica. Some platforms also use an optional sidecar or per-service reverse proxy for local TLS, telemetry, and upstream connection handling; that is a separate deployment choice, not a layer every replica needs. This costs more hops, so use only the layers that solve a real operational requirement.
How to Choose
Start with the smallest boundary that meets the requirement. A single service often needs a reverse proxy and possibly balancing. Add a gateway when API governance is repeated across services or external consumers. Add separate balancing when service replicas need independent health and capacity management. Avoid architecture driven only by product labels; monitor latency, error rates, health-check churn, and configuration complexity.
Interview Questions
1. Is an API gateway just a reverse proxy?
An API gateway generally uses reverse-proxy behavior, but its primary value is API-aware policy for consumers and services. It centralizes concerns such as authentication, rate limits, versioning, and usage visibility. A basic reverse proxy may have some of those features, but it does not need to own an API product contract. I would choose based on required responsibilities, not the binary name.
2. Can a load balancer replace an API gateway?
It can route HTTP traffic and may terminate TLS, but its central purpose is distributing requests across healthy equivalent targets. A public API often needs tenant-aware quotas, authentication policy, transformations, and developer-facing governance that do not belong in a generic balancing layer. Some managed products overlap, so I would compare their exact features and operational constraints. The underlying roles remain distinct.
3. Where should rate limiting run?
The API gateway is an efficient first control point because it rejects excess public traffic before downstream work. Services should retain domain-specific limits as defense in depth, especially for internal callers or expensive actions. A load balancer can enforce coarse connection or infrastructure limits, but it usually lacks consumer context. The trade-off is gateway state and latency versus protected backend capacity.
4. Why use a reverse proxy in front of one server?
A reverse proxy can provide TLS termination, compression, static-file handling, connection management, and a stable public address even before horizontal scaling exists. It also creates a clean migration point when the single server later becomes a pool. The extra component must be monitored and configured securely, especially for forwarded headers. It is useful when those shared edge concerns outweigh its complexity.
5. What is a common design mistake?
A common mistake is putting business orchestration into the gateway because it can call several services. That creates a central dependency with domain logic, release coupling, and difficult failure handling. Keep the gateway focused on cross-cutting API policy, then put business workflows in a dedicated service or orchestration layer. Another mistake is assuming a tool’s marketing category guarantees its deployed responsibilities.
Conclusion
- A reverse proxy manages the client-to-upstream connection and HTTP behavior.
- A load balancer distributes traffic across healthy interchangeable targets.
- An API gateway governs an API contract for consumers.
- One product can play multiple roles, so assess responsibilities rather than labels.
- Add layers only when they solve a clear security, scale, or API-governance need.
The next phase of this learning path covers database transactions and storage decisions - the persistence foundations behind reliable backend systems. Revisit database transactions and CORS for related reliability and edge-policy context, or browse the Backend category.
References
- What Is an API Gateway? - Apache APISIX https://apisix.apache.org/learning-center/what-is-an-api-gateway/
- API Gateway vs. Reverse Proxy - Baeldung https://www.baeldung.com/cs/api-gateway-vs-reverse-proxy
YouTube Videos
- “Reverse Proxy, Load Balancer, and API Gateway: The Real Difference” https://www.youtube.com/watch?v=-R5ak7-LiVY