What is an API Gateway?

Table of Contents +

Imagine you’re building an app, and in the background it’s not one big program. It’s split into many smaller programs, each doing one job:

One service handles users and logins.
One service handles orders.
One service handles payments.
And so on, until you’ve got ten of them running.

So here’s the question. When the phone app or the website wants to do something, should it just call all ten of these services directly? It sounds simple, but it gets messy fast. Let’s see why, and then meet the thing that fixes it: the API gateway.

🎯 The Problem

Let’s say there’s no gateway, and every client talks straight to every service. Here’s the pain you run into:

The client has to know the address of all ten services. If one moves or a new one shows up, you have to update the client and ship it again.
Every single service has to do its own login checks and its own rate limiting (that’s the rule that stops one user from overloading you with too many requests). So the same boring work gets copied into all ten.
When you want to change something across the board, like adding a new security check, you have to touch all ten services instead of one place.
The client ends up making a pile of separate calls to load one screen, which is slow, especially on a phone.

So calling services directly works for a tiny app, but it falls apart the moment you have more than a couple of services. We need one front door.

🚪 Real-World Analogy

Think about walking into a big office building to visit someone. You don’t just wander the hallways trying every door, right? There’s a front desk:

You walk up to reception first. It’s the one entrance everyone goes through.
The person at the desk checks who you are and whether you’re allowed in.
Then they point you to the right floor and the right room for the person you came to see.
You never need to memorize where everyone sits. The front desk knows that for you.

An API gateway is exactly that front desk for your services. Every request comes to it first, it checks you’re allowed, and then it sends you to the right service. Hold on to this picture. The rest of the lesson maps right back to it.

🛡️ What is an API Gateway

So here’s the plain definition. An API gateway is a single entry point that sits in front of all your backend services. Every client request comes to the gateway first, and the gateway routes it to the correct service. (A backend service is just one of those smaller programs we talked about, like the orders service or the payments service.)

Let’s break down what that really means:

It’s the one address the client talks to. The client doesn’t know or care that there are ten services behind it. It just talks to the gateway.
It receives every incoming request, looks at it, and decides which service should handle it. Deciding where a request should go is called routing.
It can do shared jobs in one spot, like checking logins, before passing the request along. So your services don’t each have to repeat that work.
It sits at the edge of your system, between the outside world and your private services, which is why people sometimes call it the edge of your backend.

In short, the gateway is the doorway. Everything goes in through it, and it sends each request where it needs to go.

🧩 What It Handles

The gateway isn’t just a dumb forwarder. Because every request flows through it, it’s the perfect place to handle jobs that every service would otherwise repeat. These shared jobs have a name: cross-cutting concerns. They’re things that cut across all your services, like security and logging, instead of belonging to just one.

Here’s what a typical gateway takes care of for you.

Job	What it does	In plain words
Routing	Sends each request to the right service	”This is an order, send it to the orders service”
Authentication	Checks who you are and if you’re allowed in	”Show me your ID before you come through”
Rate limiting	Caps how many requests one client can make	”Slow down, you’ve asked too many times”
Caching	Stores common answers to reuse them	”I just answered this, here it is again, fast”
Request shaping	Tweaks or combines requests and responses	”Let me tidy this up before it goes through”
Logging and monitoring	Records every request and watches the traffic	”Writing down who came in and when”

Notice the pattern. All of these would otherwise be copied into every service. The gateway does them once, in one place, for everyone.

Why one place is better

Doing auth or rate limiting in the gateway means you write and fix that logic once. Change the rule there and every service behind it gets the update instantly. No need to touch ten codebases and redeploy them all.

⚙️ How It Works

Let’s trace one request from start to finish, so you can see the gateway doing its job. Say the client wants to place an order:

The client sends the request to the gateway, not to any service directly. It’s the only address it knows.
The gateway checks the request first. Is this user logged in? Have they made too many requests already? If something’s wrong, the gateway can stop it right here.
If everything checks out, the gateway looks at the request and decides where it belongs. An order goes to the orders service, a login goes to the users service, a payment goes to the payments service.
The gateway forwards the request to that one service and waits for the answer.
The service does its work and sends the response back to the gateway, which passes it along to the client.

Here’s that whole flow as a picture. One client, one gateway, and several services behind it.

See how the client only ever touches the gateway? Everything past that box is hidden from the outside world. That’s the whole idea.

🔗 Gateway vs Load Balancer

People mix these two up all the time, so let’s clear it up. They sound similar and they often sit near each other, but they do different jobs.

A load balancer spreads traffic across many copies of the same service. Say you run five identical copies of the orders service so it can handle the load. The load balancer decides which copy each request goes to, so no single copy gets overwhelmed.
An API gateway routes requests to different services. An order goes one way, a payment goes another way. It’s about picking the right service, not picking a copy.
The gateway also adds API features on top, like auth, rate limiting, and caching. A plain load balancer doesn’t do that. Its only goal is to share out the load evenly.

And here’s the thing, they’re not rivals. They often work together. The gateway routes a request to the orders service, and a load balancer in front of that service picks which copy actually handles it. One chooses the service, the other chooses the copy.

⚡ Benefits

So why go to the trouble of putting a gateway in front of everything? Because it cleans up all the mess from the start of this lesson:

The client has just one address to talk to. It doesn’t need to know how many services exist or where they live. If you add or move a service, the client never changes.
Shared work like auth, rate limiting, and logging lives in one spot. Write it once, fix it once, and every service benefits.
Clients get simpler. Instead of juggling ten calls to load one screen, they make one call to the gateway, which can gather what’s needed in the background.
Your services stay private. The outside world only ever sees the gateway, which gives you a clean place to add security.

⚠️ Things to Watch

The gateway is great, but it comes with a catch you have to plan for. Since every single request flows through it, it sits right in the critical path:

It can become a bottleneck. If the gateway gets slow or overloaded, everything behind it feels slow, because nothing can get through without it.
It’s a single point of failure if you run only one. A single point of failure means one part whose breakdown takes down the whole system. If that one gateway crashes, your whole app goes dark, even though all the services behind it are perfectly fine.
It adds an extra hop. The request now stops at the gateway before reaching the service, which adds a tiny bit of delay.

So how do you handle this? You run more than one gateway and put them behind a load balancer, so if one dies the others keep serving. Running spare copies like this so a failure doesn’t take you down is called redundancy. Keep the gateway fast and always available, and these downsides mostly go away.

⚠️ Common Mistakes and Misconceptions

A few things trip people up when they first learn this. Let’s sort them out:

“A gateway is the same as a load balancer.” No. A load balancer spreads traffic across copies of one service. A gateway routes to different services and adds API features like auth and rate limiting. They’re related, but they’re not the same thing.
“Put all the business logic in the gateway.” Don’t. The gateway should handle routing and cross-cutting concerns like auth and logging. The real work, like calculating a price or processing an order, belongs in the services. A gateway stuffed with business logic becomes a tangled mess that’s hard to change.
“One gateway is enough.” Not in production. A single gateway is a single point of failure. Run a few copies behind a load balancer so one crash doesn’t take down your whole app.

🛠️ Design Challenge

Try this on your own to test yourself.

Imagine a food delivery app with four services: users, restaurants, orders, and payments. Sketch out a gateway sitting in front of them and answer these:

When a customer logs in, which service should the gateway route to, and where would the login check happen?
The app gets popular and one gateway starts struggling. What would you add to keep it fast and available?
A teammate wants to put the “calculate delivery fee” logic inside the gateway. Is that a good idea? Why or why not?

Work through these and you’ll have reasoned about routing, redundancy, and where logic belongs, exactly the way you would in a real interview.

🧩 What You’ve Learned

You can now explain what an API gateway is and why systems use one. Here’s what you’ve picked up.

✅ An API gateway is a single entry point that sits in front of your services and routes each request to the right one.
✅ It handles cross-cutting concerns like routing, authentication, rate limiting, caching, and logging in one place.
✅ It’s different from a load balancer: a load balancer spreads traffic across copies of one service, while a gateway routes to different services.
✅ It gives you one address for clients, shared logic in one spot, and private services.
✅ It can be a bottleneck and a single point of failure, so you run several copies for redundancy.

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

🚀 What’s Next?

This lesson gave you the front door to a service-based system. Next, go deeper into where gateways fit and one of the jobs they do.

Monolith vs Microservices explains the service-based setup where gateways really shine.
Rate Limiting Explained breaks down one of the key jobs a gateway handles for you.

Once you’ve got those, you’ll have a solid grip on how modern backends are put together.

Previous Choosing the Right Protocol Next Introduction to Databases

Share & Connect

Share on LinkedIn