API Gateway in Microservices

Table of Contents +

Picture a shopping app. You open it on your phone and the home screen shows your profile, your cart, some recommended products, your recent orders, and a few offers:

In a microservices setup, none of that lives in one place. Each piece comes from its own little service.
So to build that single screen, the phone might have to call the users service, the cart service, the products service, the orders service, and the offers service. That’s eight calls just for one screen.
Now imagine your phone doing all of that, over a slow mobile network, every time you open the app. Slow, right?

There’s a cleaner way. You put one thing in front of all those services and let it do the running around for you. That thing is the API gateway, and in this lesson we’ll see what it does specifically in a microservices world.

🎯 The Problem in Microservices

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

The client gets chatty. Chatty just means the client has to make a pile of separate network calls to do one thing, like loading that home screen. Each call costs time, and on a phone that adds up fast.
Every service has to do its own login check. So the same auth work gets copied into the users service, the cart service, the orders service, and all the rest. Repeated everywhere.
The client gets tightly tied to your internal structure. It has to know all the service addresses. So if you split a service in two or rename one, you have to update the client and ship it to every phone out there.
The outside world can see how your system is carved up. That’s both messy and a security worry.

So calling services directly might work when you have one or two of them. But the moment you have a real microservices setup with a dozen services, it falls apart. You need one front door.

🚪 The Gateway as One Entry Point

Quick recap, in case you’re jumping in here. 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 sends it on to the right service. (A backend service is just one of those small programs, like the cart service or the orders service.)

Here’s the short version of what that buys you:

The client talks to one address only. It doesn’t know or care how many services hide behind the gateway.
Your services stay private. The outside world only ever sees the gateway.
Shared work can happen in that one spot instead of in every service.

If this is your first time meeting the gateway, go read the API Gateway lesson first, then come back. This lesson builds on it and zooms into the jobs that matter most when you’ve got many services: routing, aggregation, and shared concerns.

🧩 Request Routing

The first job is the simplest one, and it’s called routing. Routing just means deciding which service a request should go to, and sending it there:

The client sends every request to the gateway, no matter what it’s for.
The gateway looks at the request and figures out where it belongs. A request about orders goes to the orders service. A request about the cart goes to the cart service.
The gateway forwards it to that one service, waits for the answer, and passes it back to the client.

So the client never has to know that orders and payments are two different services living at two different addresses. It just asks the gateway, and the gateway knows the map. That’s why you can move services around behind the gateway without ever touching the client.

🧰 Response Aggregation

Now here’s the part that really shines in microservices. Routing sends one request to one service. But remember that home screen that needed five services? Making the phone call all five is exactly the chatty problem we wanted to avoid. So the gateway does something smarter, called response aggregation.

Response aggregation means the gateway calls several services itself, gathers their replies, and combines them into one response for the client:

The client makes one call to the gateway, like “give me my home screen”.
The gateway then calls the users service, the cart service, the products service, and the orders service on its own.
It waits for all those replies, stitches them together into one neat bundle, and sends that single bundle back to the client.

So the phone makes one call instead of five. And the calls from the gateway to the services happen inside your own fast network, not over the slow mobile connection. The client’s life gets simple, and the app feels quick. People also call this service composition, because the gateway composes one answer out of many.

Here’s that whole flow as a picture. One client, one gateway, and the gateway fanning out to several services and combining what comes back.

See how the client only ever talks to the gateway? The gateway does all the fan-out and the combining. The phone never sees the four separate services at all.

Why aggregation helps mobile most

On a phone, every network call is slow and eats battery. Turning five round trips into one is a huge win. The gateway’s extra calls to the services run inside your own network, where they’re fast, so the heavy lifting moves off the phone.

🔐 Cross-Cutting Concerns in One Place

There’s a set of jobs that every service would otherwise have to do for itself, like checking logins and limiting traffic. These shared jobs have a name: cross-cutting concerns. They’re called that because they cut across all your services instead of belonging to just one. And since every request flows through the gateway anyway, that’s the perfect spot to handle them once:

Do the login check at the gateway, and the services behind it can trust that whoever got through is already allowed in.
Set the rate limit at the gateway, and you cap a noisy user before they ever reach your services.
Cache common answers at the gateway, and you skip hitting the services at all for repeat questions.

Here’s what a gateway typically handles for a microservices setup, and why doing it in one place beats copying it into every service.

Job	What it does	Why it lives at the gateway
Routing	Sends each request to the right service	Only the gateway knows the full service map
Aggregation	Combines replies from many services into one	Saves the client from making many calls
Authentication	Checks who you are and if you’re allowed in	Write the check once, not in every service
Rate limiting	Caps how many requests one client can make	Stops a noisy user at the door
Caching	Stores common answers to reuse them fast	Skips the services for repeat questions
Logging and monitoring	Records every request and watches the traffic	One spot sees all the traffic going in and out

Notice the pattern. Every one of these would otherwise get copied into all your services. The gateway does them once, for everyone, in one place. Change a rule there and every service behind it gets the update right away.

📱 The Backend-for-Frontend (BFF) Pattern

Here’s a wrinkle you hit fast. A mobile app and a web app don’t want the same thing. The phone wants a small, trimmed-down response to save data. The desktop site has a big screen and wants more detail. One gateway trying to please both ends up awkward. So we use the Backend-for-Frontend pattern, usually shortened to BFF.

A BFF is a gateway tailored to one specific type of client:

You run one gateway just for the mobile app. It aggregates and trims responses exactly the way the phone likes them.
You run another gateway just for the web app. It shapes responses the way the big screen wants them.
Each gateway speaks to the same services in the background. Only the way they bundle and shape the response differs.

So instead of one gateway twisting itself to serve every client, each client gets its own. The mobile BFF and the web BFF both do routing, aggregation, and auth, but each one is built around the needs of its own front end. That keeps each one simple and easy to change.

BFF in one line

A BFF is just an API gateway dedicated to one kind of front end. Same idea as a gateway, but you run a separate one per client type so each fits its client perfectly.

⚠️ Things to Watch

The gateway is great, but because every single request flows through it, you have to plan for a few things:

It can become a bottleneck. If the gateway gets slow or overloaded, everything behind it feels slow, because nothing reaches the services without going through it first.
It’s a single point of failure if you run only one. A single point of failure is one part whose breakdown takes down the whole system. If that lone gateway crashes, your app goes dark even though every service behind it is perfectly fine.
It’s tempting to dump business logic into it. Don’t. The gateway should route, aggregate, and handle shared concerns. The real work, like pricing an order, belongs in the services.

So how do you handle the first two? 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 light and always available, and the downsides mostly melt away.

⚠️ Common Mistakes and Misconceptions

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

“Clients should just call the services directly.” In a real microservices app, no. That makes the client chatty, ties it to your internal structure, and forces every service to repeat auth. The gateway gives clients one front door and does the fan-out for them.
“Put all the logic in the gateway.” Don’t. The gateway handles routing, aggregation, and cross-cutting concerns like auth and logging. The business logic, like calculating a total or processing a payment, stays in the services. A gateway stuffed with business logic becomes a tangled mess that’s hard to change.
“One gateway is enough, no need for backups.” 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 five services: users, restaurants, menus, orders, and payments. The home screen needs the user’s profile, nearby restaurants, and their recent orders. Sketch a gateway in front of these services and answer:

The mobile app opens the home screen. Which services does the gateway call, and how would it combine the replies into one response?
The team launches a web dashboard for restaurant owners that needs very different data. Would you reuse the same gateway or add a BFF? Why?
One gateway starts struggling under load. What would you add to keep it fast and available?
A teammate wants to put the “calculate delivery fee” logic inside the gateway. Good idea or not? Why?

Work through these and you’ll have reasoned about aggregation, the BFF pattern, 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 does in a microservices system. Here’s what you’ve picked up.

✅ In microservices, calling services directly makes clients chatty, repeats auth everywhere, and ties clients to your internal structure.
✅ The gateway is one entry point that routes each request to the right service.
✅ Response aggregation lets the gateway call several services and combine their replies into one response, so the client makes a single call.
✅ Cross-cutting concerns like auth, rate limiting, caching, and logging live once at the gateway instead of in every service.
✅ The BFF pattern runs a separate gateway per client type, like mobile and web, each shaping responses for its own front end.
✅ The gateway can be a bottleneck and a single point of failure, so keep it light, hold business logic out of it, and run redundant copies.

Check Your Knowledge

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

🚀 What’s Next?

This lesson showed you how the gateway pulls a microservices setup together. Next, go deeper into how services talk and revisit the gateway basics.

Service Mesh Basics shows how services talk to each other inside your system, beyond the front door.
API Gateway revisits the gateway fundamentals this lesson builds on.

Once you’ve got those, you’ll have a solid grip on how requests flow through a modern microservices backend.

Previous Microservices Service Communication Next Service Mesh Basics

Share & Connect

Share on LinkedIn