API Gateways in Practice: Where They Fit in Web APIs

API Gateway as a Runtime “Front Door”

An API gateway is a runtime component that sits in front of one or more backend APIs and becomes the single entry point that clients call. Instead of clients calling each backend directly, they call the gateway, and the gateway routes the request to the correct backend, applies policies (for example authentication checks), and shapes the response.

Think of it as a traffic controller for API calls: it receives HTTP requests, matches them to routes, optionally transforms/validates them, forwards them to upstream services, and returns the upstream response back to the client.

Start Simple: Client Calls a Single Service

Baseline flow (no gateway)

In the simplest setup, a client calls one backend service directly:

• Client (web/mobile/partner) sends request to https://api.example.com/orders
• DNS points api.example.com to the Orders service
• Orders service authenticates the request, validates input, applies rate limits (if any), and returns a response

This can be perfectly fine when there is only one service, few consumers, and minimal cross-cutting requirements.

Same flow with a gateway in front

Now insert a gateway as the public endpoint:

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Client calls https://api.example.com/orders (the gateway)
• Gateway matches the route /orders
• Gateway forwards to upstream http://orders-service:8080
• Gateway returns the upstream response

Even with one backend, the gateway can centralize policies so the backend can focus on business logic. But it also adds another moving part, so you should have a clear reason to include it.

Practical step-by-step: what the gateway does per request

• Receive: Accept the incoming HTTP request from the client.
• Identify: Determine which API and route the request targets (path, host, method, headers).
• Apply policies (optional): Validate auth token, enforce rate limits, check request size, validate required headers, etc.
• Route: Select the upstream backend and forward the request.
• Transform (optional): Rewrite paths, add/remove headers, normalize query parameters, map versions.
• Observe: Emit logs/metrics/traces for the request.
• Respond: Return the backend response (optionally transformed) to the client.

Why Gateways Become Useful: Multiple Backends

Gateways show their value when you have multiple backends and multiple clients. Without a gateway, each client must know each service’s address, authentication method, and quirks. With a gateway, clients see one consistent API surface while backends can evolve behind it.

Microservices example: one API surface, many services

Imagine an e-commerce system split into services:

• Orders service: /orders
• Catalog service: /products
• Payments service: /payments
• Users service: /users

Without a gateway, a mobile app might call four different hostnames, handle four auth patterns, and implement retries and timeouts per service. With a gateway, the app calls one hostname and the gateway routes internally.

Client  -- https://api.example.com/products -->  Gateway  --> Catalog service (internal)  --> response
Client  -- https://api.example.com/orders   -->  Gateway  --> Orders service (internal)   --> response
Client  -- https://api.example.com/payments -->  Gateway  --> Payments service (internal) --> response

Serverless example: gateway as a stable API in front of functions

Serverless functions are often deployed as many small endpoints that can change frequently. A gateway can provide:

• A stable base URL and versioning scheme (for example /v1, /v2)
• Consistent authentication and throttling
• Routing to different functions based on path/method

POST /v1/checkout  --> Gateway --> Function: CreateCheckoutSession
GET  /v1/orders    --> Gateway --> Function: ListOrders
POST /v1/webhooks  --> Gateway --> Function: HandleWebhook

This reduces coupling between clients and the underlying function deployment details.

Practical step-by-step: expanding from one backend to many

• Step 1: Define a single public base URL (for example https://api.example.com) that points to the gateway.
• Step 2: Create routes that map paths/methods to upstreams (service A, service B, function C).
• Step 3: Standardize cross-cutting policies at the gateway level (auth, rate limits, request size limits, CORS, etc.).
• Step 4: Keep internal addresses private so services are not directly reachable from the internet.
• Step 5: Add observability so you can see traffic per route and per consumer.

How an API Gateway Differs from Adjacent Components

API Gateway vs Reverse Proxy

A reverse proxy sits in front of servers and forwards requests to upstreams. Many gateways include reverse-proxy capabilities, but an API gateway is typically more API-aware and policy-driven.

• Reverse proxy focus: forwarding, basic routing, TLS termination, caching, compression.
• API gateway focus: API routing plus API-specific concerns like consumer authentication, per-client rate limits, request/response transformation, versioning, and developer-facing API management features (depending on product).

In practice, a gateway often uses reverse-proxy mechanics, but adds API-centric controls and configuration models.

API Gateway vs Load Balancer

A load balancer distributes traffic across multiple instances of the same service (or pool) to improve availability and throughput.

• Load balancer: “Which instance should handle this request?”
• API gateway: “Which API/service should handle this request, and what policies apply?”

You can use both: the gateway routes to a service, and a load balancer (or service discovery) spreads traffic across that service’s instances.

API Gateway vs Service Mesh

A service mesh manages service-to-service communication inside your system, usually by deploying sidecar proxies (or equivalent) alongside services.

• Service mesh: internal east-west traffic (service A calling service B), mTLS between services, retries/timeouts/circuit breaking, internal observability.
• API gateway: north-south traffic (external clients calling into the system), external authentication, edge rate limiting, API surface management.

They can complement each other: the gateway handles external entry, the mesh handles internal communication policies.

API Gateway vs BFF (Backend for Frontend)

A BFF is a backend tailored to a specific client experience (for example, one for mobile, one for web). It often aggregates data from multiple services and returns a response shaped for that client.

• BFF: client-specific orchestration and response shaping (business-level aggregation).
• API gateway: shared edge policies and routing (platform-level concerns).

You might use both: the gateway exposes /mobile/* routed to a Mobile BFF and /web/* routed to a Web BFF, while enforcing consistent auth and rate limits at the edge.

Decision Cues: When to Add a Gateway

Add a gateway when these are true

• Multiple backend services: clients would otherwise need to call many services directly or handle multiple base URLs.
• Cross-cutting concerns are repeating: authentication, authorization checks, rate limiting, request size limits, CORS, consistent error shaping, and observability are being implemented over and over.
• External-facing APIs: you need a controlled, stable entry point for partners, mobile apps, or public clients, while keeping internal services private.
• Need consistent routing and versioning: for example, /v1 and /v2 mapping to different upstreams during migrations.
• Need traffic control at the edge: throttling abusive clients, IP allow/deny lists, or protecting backends from spikes.

Practical step-by-step: quick “gateway readiness” check

• Inventory your clients: list who calls your APIs (web, mobile, partners, internal jobs) and what endpoints they use.
• Inventory your backends: list services/functions and whether they are internet-exposed.
• List cross-cutting requirements: auth method(s), rate limits, logging/metrics, request validation, versioning needs.
• Count duplicated work: if multiple services implement the same policies inconsistently, a gateway can centralize them.
• Identify stability needs: if you expect backend endpoints to change but want a stable client contract, a gateway helps decouple clients from internal topology.

When a Gateway May Be Unnecessary (or Premature)

A gateway is not mandatory for every API. It can add latency, operational overhead, and another component to secure and monitor.

Consider skipping (for now) when these are true

• Single internal service used by a small number of internal clients, with minimal policy needs.
• Few cross-cutting concerns: authentication and rate limiting are not required, or are already handled simply and consistently.
• Low change rate: the service’s endpoints and deployment topology are stable, so clients are not frequently broken by backend changes.
• Team capacity is limited: you cannot yet operate and monitor an additional runtime component reliably.

Practical alternative: keep the door open

• Use a stable DNS name for the service even if it points directly to the backend today.
• Keep routing rules simple and avoid leaking internal hostnames to clients.
• Standardize basic behaviors (error format, timeouts) in the service so adding a gateway later is less disruptive.