I Was Confused Too
Someone asked me in an interview — “Where would you put the API Gateway?”
I said “same place as the load balancer.”
The interviewer paused. Then moved on.
I failed that round.
Later I realized — I had been using both for years. I just never understood what made them different. They both sit in front of your servers. They both handle incoming traffic. So what is actually different?
This post explains it. Simply.
If you are confused about these two — you are not alone. Most developers mix them up.
🚦 The Load Balancer — Traffic Cop
Think of a load balancer as a traffic cop.
Cars come in. The cop sends them to different lanes. That is it.
The cop does not check what is in the car. Does not ask for ID. Just — car comes in, go to lane 3.
A load balancer does the same thing with network requests.
A request comes in. The load balancer sends it to one of many servers. It does not know what the request is for. It just balances the load.
That is where the name comes from.
If you want to go deeper on this — load balancers are explained here.
🚪 The API Gateway — Smart Doorman
Now think of a building with a smart doorman.
You walk up. The doorman checks your ID. Looks at where you are going. Checks if you are allowed. Then either lets you in — or sends you to the right floor.
That is an API Gateway.
It reads every request. It knows what the request is asking for. And it decides what to do with it.
Here is what an API Gateway actually does:
Authentication — checks if the person sending the request is allowed. No valid token? Request blocked. Done.
Routing — sends each request to the right service. A request for user data goes to the user service. A request for payments goes to the payment service.
Rate limiting — someone sends 1000 requests in one second? The gateway stops them. Protects everything behind it.
Logging — records every request. Who sent it, when, what they asked for.
Transformation — can change the request before passing it on. Old format in, new format out.
The load balancer does none of this. It just passes traffic.
🔍 The Simplest Way To Think About It
| Load Balancer | API Gateway | |
|---|---|---|
| What does it do? | Spreads traffic across servers | Controls what traffic can do |
| Does it read requests? | No | Yes |
| Auth / login check? | No | Yes |
| Rate limiting? | No | Yes |
| Routing by URL path? | No | Yes |
| Example tools | AWS ALB, NGINX, HAProxy | Kong, AWS API GW, Apigee |
🏗️ How They Work Together
Here is the thing nobody tells you early on.
They are not competing. Most real systems use both.
The API Gateway sits at the front. It handles all the smart stuff — auth, routing, rate limiting.
Then behind it — a load balancer spreads traffic across multiple instances of each service.
So the flow looks like this:
Client → API Gateway → Load Balancer → Servers
The gateway is the brain. The load balancer is the muscle.
From experience: I have seen teams skip the API Gateway and put all auth logic inside each service. Then six services all have different auth code. One gets updated. Five do not. Security hole. Put auth in the gateway once. Done everywhere.
🏢 Real Companies
Netflix uses an API Gateway called Zuul. Every request from the Netflix app goes through Zuul first. It checks your auth token. Routes you to the right microservice. Handles retries if a service is slow.
Amazon AWS has a service called API Gateway. Over a million developers use it. It connects to Lambda functions, EC2 servers, and other AWS services. No servers to manage.
Uber routes hundreds of millions of requests daily through their API Gateway. Different requests go to different teams’ services. Without the gateway — each team would have to handle auth and rate limiting themselves.
The load balancer at each of these companies is still there. But it works behind the gateway, not instead of it.
This is exactly why DNS → API Gateway → Load Balancer → Server is the standard order in any modern system.
✅ When To Use What
Use a load balancer when:
- Traffic is hitting one server too hard
- You need high availability — if one server dies, others take over
- You are scaling a single service horizontally
Use an API Gateway when:
- Multiple services need the same auth logic
- You want rate limiting in one place
- Different URLs need to go to different services
- You want one entry point for all external traffic
Use both when you have microservices, heavy traffic, and security requirements — which is basically always.
Engineers building CI/CD pipelines should treat the API Gateway config as code. Version it. Review it. Do not change gateway rules manually in production.
Before You Go
The interview question I got wrong was not a trick question.
It had a simple answer — the API Gateway goes in front. The load balancer goes behind. They do different things. They work together.
One reads the request. One does not care what is in it.
That is the whole difference.
Numbers and examples in this post are based on public data as of 2025.
