API Gateway

What is it?

In a microservices architecture — a system built as many small, independent services instead of one big application — a client might need data from several different services to render one screen. Every one of those services might need the same handful of things done first: authentication checked, requests logged, a rate limit enforced. An API gateway is a dedicated service that sits in front of all the others, handling exactly those shared, repeated concerns once, in one place, before forwarding each request to whichever backend service should actually handle it.

Explain like I'm 10

It's like a hotel concierge desk. Guests don't wander the building looking for housekeeping, room service, or the gym directly — they go to one desk, which checks who they are, then directs (or handles) their request appropriately, whether that means calling housekeeping or handling it right there.

Examples

A gateway handling shared concerns before routing

// Simplified API gateway middleware
async function handleRequest(req) {
  if (!isAuthenticated(req)) return { status: 401 };
  if (isRateLimited(req.userId)) return { status: 429 };

  logRequest(req);

  if (req.path.startsWith("/users")) return userService.handle(req);
  if (req.path.startsWith("/orders")) return orderService.handle(req);
}

How it works

Every client request goes to the gateway first, never directly to an individual backend service. The gateway applies shared logic — authentication, rate limiting, logging, sometimes combining data from multiple services into one response — and then routes the request to the correct backend, relaying its response back to the client.

Why does it exist?

Without a gateway, every individual microservice would need to reimplement the same authentication, rate limiting, and logging logic itself — duplicated effort, and an easy place for inconsistencies and security gaps to creep in. A gateway centralizes those shared concerns in exactly one place.

When to use it

Introduce an API gateway once you have multiple backend services that clients need to interact with, and repeated cross-cutting concerns (auth, rate limiting, logging) that would otherwise need to be duplicated across every one of them.

When not to use it

For a single backend service (or a simple monolith), an API gateway is an extra layer with no real benefit yet — it earns its place specifically once there are multiple services to unify in front of.

Common mistakes

• Letting the gateway grow so much business logic that it becomes its own tangled monolith, defeating the purpose of splitting services in the first place.

• Treating the gateway as optional infrastructure — since every request flows through it, it also becomes a critical single point of failure that needs its own redundancy.

• Forgetting that a gateway adds an extra network hop and a small amount of latency to every single request.

Practice exercises

1. Easy:

   Explain, in your own words, what problem an API gateway solves for a system with many microservices.

2. Medium:

   List three concerns that make sense to handle in an API gateway rather than in each individual backend service.

3. Hard:

   Explain why an API gateway itself needs to be highly available, given that every request passes through it.

Interview questions

What is an API gateway?

A single entry point that sits in front of multiple backend services, handling shared concerns like authentication and rate limiting, then routing requests to the correct service.

Why not just handle authentication separately in each microservice?

That duplicates the same logic across every service, increasing the chance of inconsistencies or security gaps; centralizing it in a gateway keeps it in one well-tested place.

What's a risk of putting too much logic in an API gateway?

It can grow into its own overly complex monolith, undermining the benefit of having separate, independently maintainable services behind it.