Definition
- L4 load balancer – routes by IP and port without inspecting the payload; fast, protocol-agnostic.
- L7 load balancer – inspects the HTTP request (path, headers, cookies) and routes by content.
- Reverse proxy – sits in front of backends, forwarding requests while adding TLS termination, caching, compression, and hiding backends from clients.
- API gateway – a specialized L7 reverse proxy for microservices adding authentication, authorization, rate limiting, request aggregation, and protocol translation.
- Complementary – they operate at different concern levels and stack from outside in.
The L4 load balancer is the floor manager counting heads and sending people to the shortest line. The L7 manager reads the customer's form and routes loan customers to the loan desk. The reverse proxy is the reception desk that checks umbrellas (TLS), hands out pre-printed answers (caching), and hides the back office. The API gateway is the security-and-service desk that checks ID (auth), limits how often you ask (rate limiting), and collects answers from departments (aggregation). The bank uses all three together.
Understanding the Concepts
What is a load balancer?
A load balancer distributes incoming traffic across a pool of backend instances for load spreading and high availability.
L4 vs L7
| Aspect | L4 (Transport) | L7 (Application) |
|---|---|---|
| Inspects | IP + port only | HTTP path, headers, cookies |
| Routing decisions | Destination IP/port | Content-based (path, host) |
| Speed | Extremely fast | More processing per request |
| Sticky sessions | By IP | By cookie or header |
| Protocol awareness | None (protocol-agnostic) | HTTP/HTTPS/gRPC |
| Use case | Edge, DDoS absorption | Service routing |
What is a reverse proxy?
A reverse proxy sits in front of backends and forwards client requests. The client thinks it is talking to the proxy; the real servers are hidden.
Capabilities: TLS termination, caching, compression, static content, path routing. Nginx and HAProxy are classic reverse proxies.
What is an API gateway?
A specialized L7 reverse proxy for microservices that adds API-specific concerns.
package com.bank.gateway;
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class GatewayRoutes {
@Bean
public RouteLocator routes(RouteLocatorBuilder b) {
return b.routes()
.route(r -> r.path("/api/v1/transfers/**")
.filters(f -> f
.addRequestHeader("X-Auth", "validated")
.requestRateLimiter(c -> c.setReplenishRate(100)))
.uri("lb://transfer-service"))
.build();
}
}
Why are they complementary, not alternatives?
Each handles a different concern, and they stack from outside in.
Production Stack (outside in): 1. L4 Load Balancer → spreads raw traffic across AZs, DDoS absorption 2. L7 Reverse Proxy → TLS termination, path routing 3. API Gateway → auth, rate limiting, aggregation 4. Microservices → business logic
What are common mistakes?
// WRONG: stuffing business logic into the gateway
// The gateway calculates interest rates, applies loan rules...
// → becomes a deployment bottleneck and single point of coupling
// CORRECT: gateway handles cross-cutting concerns only
// Auth, rate limiting, routing, TLS – no domain rules
When do you use which?
- L4 at the edge for raw throughput and DDoS absorption.
- L7/reverse proxy closer to services for TLS and content-based routing.
- API gateway for API-specific auth, rate limiting, aggregation.
What should a senior engineer know?
- Keep the gateway thin; a "god gateway" stuffed with business logic is an anti-pattern.
- The same software (Nginx, Envoy) can serve multiple roles depending on configuration.
- L4 and L7 categories blur because most modern load balancers do both.
- You do not pick one; you compose them, each doing what it does best.
Visual Overview
Complementary Layers (outside in)
┌──────────────────────────────────────────────────┐
│ Internet │
└──────────┬───────────────────────────────────────┘
▼
┌──────────────────┐
│ L4 Load Balancer │ IP/port routing, DDoS absorption
└────────┬─────────┘
▼
┌──────────────────┐
│ L7 Reverse Proxy │ TLS termination, caching, path routing
│ (Nginx/Envoy) │
└────────┬─────────┘
▼
┌──────────────────┐
│ API Gateway │ Auth, rate limiting, aggregation
│ (Spring Cloud GW)│
└────────┬─────────┘
▼
┌────────┐ ┌────────┐ ┌────────┐
│Transfer│ │Account │ │ Fraud │ Microservices
│Service │ │Service │ │Service │
└────────┘ └────────┘ └────────┘
Key Takeaway
A load balancer, a reverse proxy, and an API gateway are often confused because their jobs overlap, but they operate at different concern levels and in practice you stack all three. An L4 load balancer routes by IP and port without inspecting the payload, making it fast and ideal for DDoS absorption at the edge. An L7 load balancer inspects the HTTP request and routes by path, header, or cookie. A reverse proxy sits in front of backends, terminates TLS, caches responses, and hides the real servers. An API gateway is a specialized L7 reverse proxy that adds authentication, rate limiting, and request aggregation.
At National Bank of India, Pankaj layered an L4 load balancer at the edge to spread traffic across availability zones, an L7 reverse proxy for TLS termination and path routing, and a Spring Cloud Gateway for JWT authentication and per-client rate limiting. Each layer stops a different kind of problem at the right level.
The senior discipline is to keep business logic out of the gateway. A god gateway stuffed with domain rules becomes a deployment bottleneck and coupling point. The gateway handles cross-cutting concerns; domain rules stay in the services.
Remember one sentence: a load balancer spreads traffic, a reverse proxy shields backends with TLS and caching, and an API gateway adds auth and rate limiting, and because each handles a different concern they stack together as layers rather than competing as alternatives.
---