Introduction to API Gateway

On This Page

What an API Gateway Is

Why Systems Use an API Gateway

How a Request Flows Through a Gateway

API Gateway vs. Load Balancer

They Work Together

Common API Gateways

The Costs of an API Gateway

Key Takeaways

Practice Questions

A shopping app shows one home screen. To build it, the app needs the user's profile, their recent orders, and some product recommendations. Each of those comes from a different backend service, and each service has its own address.

So the phone app makes three separate calls to three addresses. Each service checks the user's login token with its own copy of the same code. And when the team moves the order service to a new address, every app must be updated.

This lesson explains the part that fixes these problems: the API gateway. It covers what a gateway is, how a request flows through it, and how it differs from a load balancer.

What an API Gateway Is

An API gateway is a server-side component that acts as an intermediary between clients and backend services.

Clients are web browsers, mobile apps, or other services that call your system.
Backend services are your microservices and APIs. Microservices are small, separate services that each do one job, like managing users or processing orders.

The main purpose of an API gateway is to provide a single entry point for external consumers to access the backend system. It receives each client request, forwards it to the appropriate microservice, and returns that service's response to the client.

Web browsers, mobile apps, and partner services all send requests to one API gateway, which forwards each request to the right microservice

Why Systems Use an API Gateway

Without a gateway, every client must know the address of every service it uses. Every service must also repeat the same shared work, like checking login tokens.

A gateway changes this in three ways.

One address for clients. Clients call the gateway, not the individual services. The gateway knows where each service runs, so the team can move or split services without changing the clients.
Shared work in one place. The gateway handles jobs that every service would otherwise repeat, like routing, authentication, and rate limiting. Rate limiting means setting a maximum number of requests that a client can make in a period of time. Each microservice can then focus on its own work.
Better performance and scalability. Shared jobs run once at the gateway instead of in every service. The gateway can also cache responses and spread requests across several copies of a service.

Without a gateway, the app calls every service and each service repeats the same checks, while with a gateway the app makes one call and the checks happen once

How a Request Flows Through a Gateway

Here is what a typical gateway does with one request.

Receive. The client sends a request, like GET /orders?user=42, to the gateway's address.
Authenticate. The gateway checks the user's login token. If the token is missing or invalid, the gateway rejects the request immediately.
Rate limit. The gateway checks whether this client has made too many requests recently. If so, it rejects the request with an error, like 429 Too Many Requests.
Route. The gateway uses the URL of the request to choose the right service and forwards the request to it.
Return. The service responds, and the gateway sends the response back to the client.

The gateway receives a request, checks the token, checks the rate limit, routes by URL to the right service, and returns the response

The routing rules are often a simple table that maps URL paths to services.

GET  /users/42          ->  user service
GET  /orders?user=42    ->  order service
GET  /products/9001     ->  product catalog service

Requests that fail authentication or rate limiting are stopped at the gateway, so they never use any backend service's resources.

Gateways can do much more. For example, a gateway can combine responses from several services into one response. It can convert between formats, like XML and JSON. It can also send old and new clients to different versions of an API. The Usage of API Gateway lesson covers these jobs.

API Gateway vs. Load Balancer

API gateways and load balancers are easy to confuse. Both sit in front of your servers, and both decide where a request goes. But they decide different things.

An API gateway is focused on routing. It sends each request to the appropriate microservice.

A load balancer is focused on distributing. It spreads requests evenly across a group of backend servers.

They also handle different kinds of requests.

An API gateway handles API requests. Each request has a specific URL that identifies which API the client wants. The gateway routes the request to the right microservice based on that URL.
A load balancer handles requests sent to a single, well-known IP address. It routes each request to one of many backend servers, based on things like server performance and availability.

A gateway routes requests by URL to different services, while a load balancer spreads requests across identical servers

	API gateway	Load balancer
Focused on	Routing	Distributing
Decides using	The URL that identifies the API	Server performance and availability
Behind it	Different services doing different jobs	Many servers doing the same job
Question it answers	Which service should handle this?	Which server should handle this?

The "Behind it" row is the easiest way to tell them apart. A load balancer chooses between servers that are the same. A gateway chooses between services that are different.

They Work Together

Real systems usually use both.

The gateway runs as several copies, for capacity and reliability. A load balancer spreads client traffic across those copies.
Each microservice also runs as several copies. After the gateway picks the right service, a load balancer, or the gateway itself, picks one healthy copy of that service.

The Introduction to Load Balancing lesson explains how load balancers work.

Common API Gateways

Managed cloud services, like Amazon API Gateway, Azure API Management, and Google Cloud Apigee. The cloud provider runs and scales them.
Self-hosted software, like Kong, or gateways built on Nginx or Envoy. Your team runs them.

The Costs of an API Gateway

A gateway also brings costs.

A possible single point of failure. All traffic passes through the gateway, so an outage there can affect the whole system. Teams run several gateway copies to avoid this.
An extra hop. Every request passes through one more server, which adds a little latency.
One more system to run. The gateway's rules must be configured, tested, and kept up to date.

The Advantages and Disadvantages of Using API Gateway lesson covers these trade-offs in detail.

Key Takeaways

An API gateway is a server-side component that acts as an intermediary between clients and backend services.
Its main purpose is to provide a single entry point for external consumers to access the backend system.
It receives a request, forwards it to the appropriate microservice, and returns the response to the client.
It handles shared jobs, like routing, authentication, and rate limiting, in one place, so each microservice can focus on its own work.
An API gateway is focused on routing requests to the right service, based on the URL. A load balancer is focused on distributing requests across identical servers.
Real systems use both, and run several gateway copies, so the gateway is not a single point of failure.

An API gateway gives clients one address and handles shared rules in one place, so services can stay small and simple. The next lesson, Usage of API Gateway, covers the main jobs that gateways do in real systems.

Practice Questions

Try each question first, then open the answer.

1. A mobile app's home screen needs data from the user service, the order service, and the recommendation service. How can an API gateway reduce the work the app does?