Reverse proxy vs API gateway vs load balancer

Core Technical Concepts to Explain

1. The Identity Crisis: All three tools do “proxying” but serve fundamentally different purposes

   • Reverse Proxy: Client-agnostic request forwarding

   • API Gateway: API-centric with business logic

   • Load Balancer: Pure traffic distribution

2. The Overlap Problem: Why people confuse them

   • Modern tools blur boundaries (NGINX can do all three)

   • Marketing terms used interchangeably

   • They can work together in the same stack

3. Decision Framework: When to use what

   • Not just “which is better” but “which solves your actual problem”

Big Tech Insights (Things Most Articles Don’t Cover)

1. At scale, you use ALL THREE together:

   • Load Balancer at edge (AWS ALB)

   • API Gateway behind it (Kong, custom)

   • Reverse Proxies in front of services (NGINX)

   • This is how Netflix, Uber, Amazon actually work

2. The “Smart Pipe vs Dumb Pipe” debate:

   • Load balancers should be dumb (just route)

   • API Gateways accumulate business logic over time (becomes maintenance nightmare)

   • Reverse proxies are the sweet spot for caching/SSL

3. Failure modes are different:

   • Load Balancer failure = complete outage

   • API Gateway failure = can bypass with direct routing

   • Reverse Proxy failure = service still accessible

4. The performance hierarchy:

   • Hardware LB (F5) > Software LB (HAProxy) > API Gateway (Kong) > Reverse Proxy doing routing

   • But flexibility is inverse

5. SSL/TLS termination placement matters:

   • Terminate at LB = one certificate, less CPU on servers

   • Terminate at Gateway = can inspect/modify encrypted traffic

   • End-to-end = secure but performance cost

6. Health check strategies differ:

   • LB: TCP/HTTP health checks (simple)

   • Gateway: Can do semantic health checks (check dependencies)

   • Reverse Proxy: Usually just “is the process up”

Content Architecture

Article Flow:

1. The Confusion (100 words)

   • Story: Junior engineer asked “should I use NGINX or AWS ALB?”

   • The answer: “What problem are you solving?”

   • All three can proxy HTTP requests but that’s where similarity ends

2. What Each Actually Does (250 words)

   • Load Balancer: Traffic cop at the entrance

     • L4 vs L7 distinction

     • Health checks and failover

     • Examples: HAProxy, AWS ALB/NLB

   • Reverse Proxy: Security guard + cache

     • SSL termination

     • Static content serving

     • Request/response modification

     • Examples: NGINX, Apache

   • API Gateway: The smart middleware

     • Authentication/Authorization

     • Rate limiting per API key

     • Request transformation

     • API composition

     • Examples: Kong, AWS API Gateway, Apigee

3. The Real Architecture (150 words)

   • How they work together

   • Real example: Netflix stack

   • Why you need different layers

4. Decision Framework (150 words)

   • Simple app: Just reverse proxy

   • Multiple services: Add load balancer

   • External APIs: Add API gateway

   • Table showing use cases

5. Common Mistakes (100 words)

   • Using API Gateway for internal services (overhead)

   • Not having load balancer for HA

   • Putting business logic in gateway

6. Practical Implementation (100 words)

   • Point to demo

   • What the demo shows

Diagrams Needed

Diagram 1: Traffic Flow Comparison

• Three parallel flows showing same request through each component

• Show what each layer does (inspects, transforms, routes)

• Highlight the differences in “intelligence”

• Visual: Request → [Component] → Backend

  • Load Balancer: Just routes based on algorithm

  • Reverse Proxy: SSL termination + caching

  • API Gateway: Auth + rate limit + transform

Diagram 2: Production Stack (How They Work Together)

• Layered architecture showing:

  • Internet → Load Balancer (AWS ALB)

  • → API Gateway (Kong) for external APIs

  • → Reverse Proxy (NGINX) in front of each service cluster

  • → Microservices

• Show what each layer provides

• This is the “aha moment” diagram

Demo Architecture

What to Build: A single-stack demo showing all three in action with real traffic:

1. Load Balancer Layer: HAProxy

   • Distributes requests to 2 API Gateway instances

   • Shows round-robin distribution

   • Dashboard shows which backend got the request

2. API Gateway Layer: Kong (lightweight)

   • Two instances behind HAProxy

   • Implements rate limiting (5 req/min)

   • Adds API key authentication

   • Logs all transformations

3. Reverse Proxy Layer: NGINX

   • Behind each Kong instance

   • Caches GET requests (30s TTL)

   • Serves static content directly

   • SSL termination

4. Backend Services: Simple Flask/Express apps

   • Return JSON with identity and timestamp

   • Log which layer headers they receive

5. Dashboard (Modern React UI):

   • Real-time request flow visualization

   • Shows: Client → LB → Gateway → Proxy → Service

   • Color codes: cache hit (green), rate limited (red), normal (blue)

   • Metrics: request count per layer, latency, cache hit rate

   • Live logs stream

   • Request simulator (send 10 requests, see rate limiting in action)

Tech Stack:

• HAProxy (load balancer)

• Kong (API gateway) - using docker image

• NGINX (reverse proxy)

• Node.js/Express for backend services (lightweight)

• React + WebSocket for dashboard

• Docker Compose to orchestrate

• Prometheus + simple metrics endpoint for stats

Demo Flow:

1. User hits dashboard

2. Click “Send Request” button

3. Watch request flow through all layers

4. Try rapid requests → see rate limiting

5. Try repeated GET → see caching

6. Stop one backend → see LB failover

Common Confusions to Address

1. “Can’t NGINX do load balancing?”

   • Yes, but it’s primarily a reverse proxy that CAN load balance

   • Dedicated LBs have better algorithms, health checks, failover

2. “Is API Gateway just a fancy reverse proxy?”

   • No, it’s API-aware (understands REST, GraphQL, gRPC)

   • Has business logic (rate limiting per user, not just per IP)

3. “Do I need all three?”

   • Depends on scale and architecture

   • Most startups: just reverse proxy

   • Growing: add load balancer

   • API-first: add gateway

Real Production Examples

1. Netflix:

   • AWS ELB → Zuul (API Gateway) → NGINX → Microservices

   • Each layer has specific purpose

2. Uber:

   • Hardware LB → Custom API Gateway → Envoy Proxy → Services

   • Millions of requests/second

3. Shopify:

   • LB for HA → No API Gateway (direct to services) → NGINX

What Makes This Different from Other Articles

• Most articles compare them as alternatives

• This shows they work TOGETHER

• Actual demo showing all three in one stack

• Real examples from big tech

• Decision framework, not just definitions

• Shows failure modes and performance characteristics

Learning Outcomes

After reading:

1. Understand each tool’s PRIMARY purpose

2. Know when to use which (or all)

3. See how they work together in production

4. Avoid common mistakes

5. Have working code to experiment with

Changed/Updated Since Last Year

• Kong 3.x is now stable (use this version)

• NGINX now has better API Gateway features (NGINX Plus) - mention this

• AWS API Gateway v2 has HTTP API (cheaper, faster) - reference this

• Envoy proxy gaining popularity - worth mentioning as modern alternative

• HAProxy 2.8+ has better observability

• Service mesh (Istio/Linkerd) is alternative approach - brief mention

</planning>

I’ll create a comprehensive article with working demo showing all three technologies working together in a single stack. Let me start:

Proxy Showdown: Reverse Proxy vs. API Gateway vs. Load Balancer

A junior engineer on my team once asked: “Should I use NGINX or AWS ALB?” My response: “For what?” He looked confused. “For... proxying requests?”

Here’s the thing—all three can proxy HTTP requests, but that’s like saying a sedan, a truck, and a bus all have wheels. Technically true, but they solve completely different problems.