API Gateway Pattern

An API gateway is a single entry point that sits between external clients and your backend services, handling request routing, authentication, rate limiting, and protocol translation.

What It Really Means

Without an API gateway, a mobile app that needs data from five microservices would make five separate HTTP calls to five different hosts with five different authentication mechanisms. The client needs to know the address of every service, handle different response formats, and manage retries independently. This couples clients tightly to your backend topology.

An API gateway solves this by providing a single, stable endpoint. The mobile app makes one call to api.example.com/orders/123, and the gateway handles routing to the Order Service, enriching the response with data from the User Service, enforcing rate limits, verifying the JWT token, and transforming the response format. The client sees a clean, unified API regardless of how many services exist behind it.

The pattern originated from the need to decouple client development from backend decomposition. When you split your monolith into microservices, you do not want mobile apps to update their code every time a service boundary changes. The gateway absorbs that complexity.

How It Works in Practice

Core Responsibilities

Request Routing: Maps external URLs to internal services. GET /api/products/123 routes to the Product Service, POST /api/orders routes to the Order Service. Clients never interact with internal service addresses.

Authentication and Authorization: Validates JWT tokens, API keys, or OAuth tokens at the gateway level. Backend services receive pre-validated requests with user identity in headers, eliminating duplicated auth logic.

Rate Limiting: Enforces request limits per API key, per user, or per endpoint. Protects backend services from traffic spikes and abuse.

Request Aggregation: A single client request may require data from multiple services. The gateway fans out to multiple backends and aggregates responses, reducing client round trips. This is particularly important for the BFF pattern.

Protocol Translation: External clients use REST/HTTP; internal services may use gRPC, WebSocket, or message queues. The gateway translates between protocols.

Response Transformation: Different clients need different response shapes. A mobile app needs a compact response; a web dashboard needs the full payload. The gateway transforms responses per client.

Real-World Example: Netflix Zuul

Netflix's API gateway handles all API requests from their client applications. It performs:

• Dynamic routing to over 1,000 backend services
• Authentication and session management
• Device-specific response formatting (TV, phone, tablet, browser)
• A/B test routing based on user segments
• Load shedding during traffic spikes

All of this is transparent to backend service teams. They expose internal APIs and the gateway handles external presentation.

Implementation

Using Kong (API Gateway)

Custom Lightweight Gateway in Node.js

Trade-offs

When to Use an API Gateway

• You have multiple backend services that external clients need to access
• Authentication and rate limiting should be centralized rather than duplicated
• Different clients (mobile, web, IoT) need different API shapes (see BFF pattern)
• You need to decouple client-facing APIs from internal service topology
• You want unified logging, metrics, and tracing for all external traffic

When NOT to Use an API Gateway

• Single backend service — the gateway adds unnecessary complexity
• Internal service-to-service communication — use a service mesh instead
• The gateway becomes a monolithic bottleneck with too much business logic
• Simple static sites or server-rendered applications with no API layer

Advantages

• Single entry point simplifies client code and security
• Cross-cutting concerns (auth, rate limiting, logging) handled once
• Backend services can evolve independently without breaking clients
• Enables protocol translation and response aggregation

Disadvantages

• Single point of failure — requires high availability setup
• Added latency — every request goes through an extra hop
• Risk of becoming a "smart pipe" — business logic creeping into the gateway
• Configuration complexity grows with the number of routes and policies
• Team ownership can be ambiguous — is the gateway owned by platform or product teams?

Common Misconceptions

• "An API gateway replaces a load balancer" — They operate at different layers. A load balancer distributes traffic across instances of the same service. An API gateway routes requests to different services based on path, headers, or other criteria. Most architectures use both.

• "API gateways and service meshes do the same thing" — An API gateway handles north-south traffic (external clients to internal services). A service mesh handles east-west traffic (service-to-service). They are complementary layers.

• "You should put business logic in the gateway" — The gateway should handle cross-cutting infrastructure concerns only. Putting business logic (validation, transformation, orchestration) in the gateway creates a distributed monolith and a deployment bottleneck.

• "One gateway fits all clients" — Different clients have different needs. A mobile app needs compact responses; a partner API needs full payloads. The BFF pattern addresses this with client-specific gateways.

• "API gateways are only for microservices" — Even monoliths benefit from a gateway for centralized auth, rate limiting, and SSL termination. The gateway is about managing the external interface, not about the backend architecture.

How This Appears in Interviews

API gateway questions are common in system design interviews:

• "Design the API layer for a mobile e-commerce app" — discuss the gateway as the entry point, authentication flow, rate limiting, and response aggregation. See our system design interview guide.
• "How would you handle API versioning?" — discuss URL path versioning at the gateway level, header-based versioning, and backward compatibility.
• "Your API has different consumers (mobile app, web, partners). How do you serve them all?" — introduce the BFF pattern with client-specific gateways.
• Practice with our API design interview questions.

Related Concepts

• BFF Pattern — Client-specific API gateways
• Service Mesh — East-west traffic management
• Microservices Architecture — The architecture API gateways serve
• Event-Driven Architecture — Async communication beyond the gateway
• Compare: Kong vs AWS API Gateway — Choosing a gateway implementation
• System Design Interview Guide — Comprehensive preparation
• Algoroq Pricing — Practice API design questions