🚦Balancers,

Reverse Proxy, Load

and API Gateways:
Untangling the Web Traffic
Puzzle
Hi I am a 16 year old developer and like many teenage developers, I started with
passion projects — React apps, small Node backends, and full‑stack builds with
[Link]. Creating them was exciting, but eventually, I hit a bigger, more
fundamental question:
👉 What separates a side‑project app from a truly global platform that can
handle millions of users, all without buckling under pressure?
I realized that building a feature is one thing, but scaling it so that real-world users
can rely on it every second is something else [Link] question led me down a
rabbit hole into the foundational layers of software architecture—the unsung
heroes that operate in the background. I discovered that the magic isn't just in the
code you write, but in the infrastructure that orchestrates it. Specifically, I became
fascinated by three powerful technologies: reverse proxies, load balancers, and
API gateways.

These aren't just boring "enterprise" concepts. They are the traffic cops,
translators, and security guards of the digital world, and understanding them is
the difference between being a coder and an architect.
In this deep dive, I'll deconstruct these pillars of modern web infrastructure, share
the open-source tools you can use to master them, and explain how cloud giants
like AWS implement them at a planetary scale.

🔹 The Foundation: What is a Reverse Proxy?

Before we can run, we must walk. A reverse proxy is the fundamental building
block upon which more complex systems are built.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 1
 Think of a reverse proxy as the front desk receptionist and security detail for
your entire web application. Instead of every user connecting directly to your
application server (which is like giving out your home address to strangers), all
incoming traffic is first intercepted by the reverse proxy.

🔍 Deep Dive: The "Why" and "How"

A direct connection to a server is risky and inefficient. The reverse proxy sits in a
DMZ (Demilitarized Zone), a neutral network segment between the scary public
internet and your trusted private network.
What it does in detail:

Security & Obscurity: This is the primary role. It hides the characteristics and
IP addresses of your backend origin servers. Attackers can't directly target
what they can't see, mitigating threats like DDoS attacks on your actual
infrastructure.

SSL/TLS Termination: Encrypting and decrypting HTTPS traffic is

computationally expensive. The reverse proxy can handle this SSL handshake,
freeing up your application servers to use their CPU cycles for what they do
best: running your application logic. It then communicates with the backend
servers over an unencrypted HTTP connection (often on a private network) or
re-encrypts it for an internal secure channel (mTLS).

Caching: For static assets—images, CSS, JavaScript files, even entire HTML
pages—the reverse proxy can store a copy. When a user requests these
assets, the proxy serves them directly from its memory without ever bothering
the backend. This drastically reduces latency and server load.

Compression: The proxy can gzip compress responses before sending them
to the client, saving bandwidth and speeding up page load times.

Basic Routing: It can look at a request (e.g., the URL path like
/static/images/[Link] ) and decide where to send it, acting as a simple router.

💡 Real-World Analogy: Imagine a famous author. You don't send fan mail directly
to their private home. You send it to their publisher's P.O. box. The publisher (the
reverse proxy) receives it, filters out anything malicious, bundles it, and then
forwards the safe, relevant mail to the author.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 2
 🔧 Open-Source Tools to Experiment With
Nginx: The undisputed king. It's incredibly fast, lightweight, and powerful. Its
configuration file ( [Link] ) is where you learn the semantics of routing and
proxying. Most of the web runs on it.

Apache HTTP Server: The venerable veteran. While often used as a direct
web server, its mod_proxy module makes it a capable and highly customizable
reverse proxy.

Traefik: The new, cloud-native contender. Its killer feature is automatic

service discovery. If you're using Docker or Kubernetes, Traefik automatically
detects new containers and configures itself, which is pure magic.

☁️ How AWS Does It: The Cloud Scale

In AWS, you don't just install Nginx on a server (though you can). They offer
managed services that abstract the underlying machine:

Amazon CloudFront: This is a Global Reverse Proxy + CDN. It operates at the

edge, meaning it has data centers all over the world. It caches your content
geographically close to your users and acts as the first point of contact for all
traffic.

Application Load Balancer (ALB): While technically a load balancer (more on

that next), an ALB is, at its core, a sophisticated Layer 7 (HTTP/HTTPS)
reverse proxy with advanced routing capabilities.

🔹 Scaling Out: What is a Load Balancer?

So you have a reverse proxy protecting your single server. But what happens
when that one server just can’t keep up? Users keep coming, traffic spikes, and
suddenly one machine isn’t enough. The natural next step is to add more servers.
But now you face another problem:

👉 How do you make sure users are evenly spread across these servers,
instead of everyone piling onto just one?
That’s where a load balancer comes in.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 3
 A load balancer is like the air traffic controller of your application fleet. Its core
purpose is to distribute incoming traffic across multiple backend servers, ensuring
no single server becomes a bottleneck. This improves performance, availability,
and fault tolerance.

🔍 Deep Dive: Layer 4 vs Layer 7 Load Balancing

Load balancers don’t all work the same way—they operate at different layers of
the OSI model:

Layer 4 (Transport Layer) – Works at the TCP/UDP level. It doesn’t care what’s
inside the packet (like HTTP headers); it just forwards traffic based on IP
address and port.

Pros: Very fast, minimal overhead.

Cons: Less intelligent—it can’t look into the actual content of requests.

Layer 7 (Application Layer) – Works at the HTTP/HTTPS level (and beyond). It

understands application-level data like URLs, cookies, headers, and even
request methods (GET, POST).

Pros: Smarter. Can route traffic based on paths ( /api vs /static ), domains,
or even user data.

Cons: More CPU-intensive because it inspects every request deeply.

💡 Analogy:
Layer 4 is like a postal sorting facility—it just checks the address and forwards
the package.

Layer 7 is like a customs officer—it opens the package, looks inside, and
decides how to handle it based on its contents.

🔍 How Does It Decide? Load Balancing Algorithms

A load balancer’s secret sauce is the algorithm it uses to decide which server gets
the next request. Here are the most common strategies, explained in depth:

1. Round Robin

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 4
 Requests are sent to servers in order: Server A → Server B → Server C →
back to A.

Best for: Simple, predictable workloads where all servers are roughly
equal.

Weakness: Doesn’t account for servers being overloaded or requests

having different sizes.

2. Least Connections

The load balancer tracks how many active requests each server is
currently handling. The next request goes to the server with the fewest
active connections.

Best for: Applications where some requests are heavier than others (like
video streaming vs. serving images).

Weakness: Can get skewed if a “light” connection hangs around for a long
time.

3. IP Hash

The client’s IP address is hashed (turned into a number), and that number
decides which server the user always goes to.

Best for: Situations where users need “stickiness” (session persistence),

like shopping carts or login sessions.

Weakness: Uneven distribution if most users come from a few IP ranges.

4. Weighted Round Robin / Weighted Least Connections

Not all servers are equal—some may have more CPU or RAM. You can
assign weights so stronger servers get more traffic.

Best for: Clusters with mixed server hardware.

5. Random / Hash-based Balancing

Sometimes a pseudo-random function or hashing on request attributes

(like cookies or headers) is used to spread load.

Best for: Situations where uniform distribution is required without

complexity.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 5
 💡 Analogy for Algorithms: Imagine a restaurant:
Round Robin: The host seats guests at tables in order.

Least Connections: Guests are seated at the table with the fewest people
already sitting.

IP Hash: Each guest’s ID number determines which table they always sit at.

Weighted: Bigger tables get more guests than smaller ones.

🔧 Open-Source Tools to Experiment With

HAProxy – Battle-tested, handles massive volumes of traffic, with advanced
algorithms.

Nginx – Its upstream module makes it a versatile Layer 7 load balancer.

Envoy – Modern, dynamic load balancer built for microservices and service
meshes.

☁️ How AWS Does It: Elastic Load Balancing (ELB)

AWS provides Elastic Load Balancing (ELB), a fully managed service with
different flavors of load balancers:

Application Load Balancer (ALB) – Operates at Layer 7.

Can route based on request path, domain name, or headers.

Perfect for microservices or container-based apps.

Supports WebSockets and HTTP/2.

Network Load Balancer (NLB) – Operates at Layer 4.

Extremely fast, handles millions of requests per second.

Designed for ultra-low latency and high-throughput apps like gaming or

fintech.

Supports static IPs, making it easier to integrate with firewalls.

Gateway Load Balancer (GWLB) –

Unique to AWS, sits at Layer 3/4.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 6
 Designed to insert third-party appliances (firewalls, intrusion detection,
deep packet inspection) seamlessly.

Uses GENEVE protocol to pass traffic transparently with metadata intact.

🔹 The Modern Orchestrator: What is an API Gateway?

As applications evolved from monoliths into distributed microservices, a new
problem emerged. How do you efficiently manage, secure, and monitor all the API
communication between these dozens or hundreds of tiny services? Enter the API
Gateway.

An API Gateway is a highly specialized reverse proxy designed exclusively for

API traffic. It's the bouncer, translator, accountant, and manager all rolled into
one.

🔍 Deep Dive: The Feature Set

While a reverse proxy handles generic web traffic, an API Gateway provides API-
specific features:

Authentication & Authorization: The gatekeeper. It can validate API keys,

verify JSON Web Tokens (JWTs), and integrate with OAuth providers (like
Auth0 or Amazon Cognito) before a request even touches your backend.

Rate Limiting & Throttling: Protects your backend from being overwhelmed by
a single abusive client or a DDoS attack. You can define rules like "Client X
can only make 1000 requests per minute."

Request/Response Transformation: The translator. Your backend service

might return data in XML, but a mobile client expects JSON. The gateway can
transform it on the fly, saving you from writing boilerplate code in every
service.

API Composition & Aggregation: A mobile app might need data from three
different microservices to load a single screen. Instead of the client making
three separate calls, the gateway can make one request, call all three services
internally, aggregate the results, and send back a single, unified response.
This is a huge performance win for clients on slow networks.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 7
 Detailed Monitoring & Analytics: It provides centralized logs, metrics, and
often tracing data for every API call, giving you a complete picture of your API
ecosystem's health and usage patterns.

💡 Real-World Analogy: Imagine a high-end nightclub. The bouncer (API

Gateway) checks your ID (Authentication), ensures the club isn't over capacity
(Rate Limiting), and tells the bartender your specific drink order in the right
terminology (Transformation). The manager (Gateway) also keeps track of how
many drinks are sold and which are most popular (Analytics).

🔧 Open-Source Tools to Experiment With

Kong Gateway: Built on top of Nginx, Kong is extensible via a rich ecosystem
of plugins for auth, security, and monitoring. It's a powerhouse.

Tyk: Another full-featured open-source gateway, known for its clean

dashboard and developer-friendly approach.

KrakenD: Focuses on performance and API aggregation. It's designed to be

stateless and blazingly fast.

☁️ How AWS Does It: Amazon API Gateway

This is a fully managed service that lets you create, publish, and secure APIs at
any scale without managing any servers.

REST & WebSocket APIs: Supports both request-response and persistent

connections for real-time applications.

Serverless Integration: Its deepest integration is with AWS Lambda. You can
create an API where every request triggers a Lambda function, creating a
completely serverless, infinitely scalable backend. This is a game-changer for
cost and operational overhead.

Stages and Versioning: You can deploy your API to different stages (e.g., dev ,
test , prod ) and easily manage versions.

Usage Plans & API Keys: Allows you to create monetized APIs or offer tiered
access to developers.

🔹 Side-by-Side: Choosing the Right Tool

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 8
 It's not always either/or. These technologies often work together in layers. Here's
how to think about them:

Feature Reverse Proxy 🛡️ Load Balancer ⚖️ API Gateway 🚪

API Management,
Security, SSL, Distribution, High
Primary Purpose Security,
Caching Availability
Transformation

Primarily Layer 7 Layer 4 (TCP/UDP) or

Operates At Layer 7 (HTTP/HTTPS)
(HTTP) Layer 7

Distributes traffic Understands API

Key First point of contact
across identical semantics (endpoints,
Differentiator for all traffic
servers methods)

AWS Managed CloudFront, ALB ALB, NLB,

Amazon API Gateway
Service (function) GWLB(ELB)

You have
You need to hide You have multiple
(micro)services and
Use When... servers and cache instances of the same
need to manage API
content. server.
traffic.

A typical modern architecture might look like this: Internet -> CloudFront (Reverse Proxy/CDN)
-> ALB (Load Balancer) -> Amazon API Gateway -> Lambda Functions (Backend Logic)

🚀ECR,Hosting a Spring Boot App on AWS with

ECS, Load Balancer, and API Gateway
I built a simple Task Manager app:

The frontend is React (runs on my laptop).

The backend is Spring Boot (runs on AWS).

The main goal was to learn and explain load balancers, and API gateways using
AWS services.
Let’s go step by step and explain how I did it.

🔹 Step 1: Amazon ECR (Elastic Container Registry)

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 9
 👉 Think of ECR as GitHub for Docker images.
A Docker image is like a packaged version of your app that includes
everything it needs to run.

ECR is just a place to store these images safely in AWS so that other AWS
services can use them.

Commands to push your Spring Boot app image to ECR:

1️⃣ Login to ECR:
aws ecr get-login-password --region ap-south-1 | docker login --username A
WS --password-stdin <account-id>.[Link]

2️⃣ Create a repo in ECR:

aws ecr create-repository --repository-name taskmate-backend

3️⃣ Build your Docker image:

docker build -t taskmate-backend .

4️⃣ Tag the image (so AWS knows where to put it):
docker tag taskmate-backend:latest <account-id>.[Link]
[Link]/taskmate-backend:latest

5️⃣ Push the image to ECR:

docker push <account-id>.[Link]/taskmate-bac
kend:latest

✅ Done! Now your app is inside AWS in the form of a Docker image.
🔹 Step 2: Amazon RDS (Relational Database Service)
🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 10
 👉 Think of RDS as “a database running on AWS so you don’t have to install
PostgreSQL on your laptop.”

I created a PostgreSQL database on RDS.

Gave it a name, username, password.

I used the sandbox template for the purpose of the project as it is in free tier.

AWS gave me an endpoint (like a URL) which my app uses to connect to the
database.

📌 Without RDS, I’d have to manage the database myself (updates, security,
backups). With RDS, AWS does it for me.

🔹 Step 3: Amazon ECS (Elastic Container Service)

👉 ECS is like a babysitter for Docker containers.
A container is just a running version of a Docker image.

ECS makes sure your container keeps running, even if one crashes.

We used the Fargate option → which means AWS manages the servers for us
(serverless containers).

Steps I did:

1. Created an ECS cluster (a group where containers live).

2. Created a Task Definition (a recipe that says:

which Docker image to run,

which port to expose,

what environment variables like database URL and password to use).

3. Created a Service → this runs the task definition and keeps it alive.

🔹 Step 4: Application Load Balancer (ALB)

In my setup:

When creating ECS service it gives you an option to a load balancer.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 11
 I created an Application Load Balancer (ALB).

The ALB listens on port 80 (HTTP).

It forwards requests to the ECS container running on port 8080.

Added a target group which connects load balancer to my containers in ECS

service.

Added a health check connected to a predfined endpoint in my backend code.

So now, instead of connecting directly to ECS, I connect to:

[Link]

This address is given by AWS automatically when you create the load balancer.

🔹 Step 5: Amazon API Gateway

Steps I did:

1. Went to API Gateway → Create API → HTTP API.

2. Named it.

3. Created an Integration → pointed it to the ALB DNS.

4. Added a route:

ANY /{proxy+} → ALB Integration

(this means “forward any request to the ALB”).

5. Deployed it to the $default stage.

Now my backend is available at:

[Link]

🔹 Why Use All of This?

Let’s break it down in super simple terms:

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 12
 ECR → stores my Docker app image. (like GitHub for Docker)

ECS → runs the Docker image in AWS. (container orchestration)

RDS → gives me a ready-to-use database. (no need to install PostgreSQL)

ALB → balances traffic between containers

API Gateway → the main entry point with extra features like security and
routes.

🔹 Final Flow
👉 When someone opens my API Gateway URL:
1. API Gateway gets the request.

2. It passes it to the Load Balancer (ALB).

3. ALB sends it to one of my ECS containers.

4. My container (Spring Boot app) connects to the RDS database.

5. The response goes all the way back to the user.

React (Frontend on laptop) → API Gateway → Load Balancer → ECS (Spring B

oot) → RDS (Database)

This project was a hands-on demo of how AWS services (ECR, ECS, ALB, API
Gateway, RDS) fit together to host a backend app.
It also showed how load balancers and api gateways work in the real world.

🔹 Why This Architectural Thinking Matters

When I started, my goal was to make code work. Now, my goal is to make systems
work. Learning these concepts shifted my mindset from syntax to structure.
You can write the most elegant Python code, but if it's running on a single server
with no protection, it will fail under real-world pressure. Architecture is the art of
designing systems that are resilient, scalable, and secure by default.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 13
 It's the difference between building a treehouse and designing a skyscraper. Both
provide shelter, but one requires a deep understanding of load-bearing walls,
foundation pilings, and elevator systems.

✨ Final Thought
At 16, diving into architecture has taught me that the most beautiful code is the
code you don't have to write because you built a smarter system around it.
Reverse proxies, load balancers, and API gateways are the unsung heroes that let
application developers focus on creating value.
True craftsmanship in software isn't just about building features; it's about
building foundations that allow those features to shine for everyone, everywhere,
all at once.

This article explores what these three technologies do, how they differ from each
other, why load balancers are the unsung heroes of scalability, and which AWS
services you can implement for each solution.

🚦 Reverse Proxy, Load Balancers, and API Gateways: Untangling the Web Traffic Puzzle 14