software-architecture-design

API Gateway Pattern

4 min read

API Gateway Pattern

A microservices pattern in which a single entry point (the API Gateway) sits between external clients and backend services, routing requests and centralizing cross-cutting concerns like authentication, rate limiting, SSL termination, and response aggregation.

Problem

In a microservices architecture, external clients (web, mobile, third-party) need to interact with multiple services. Without a gateway, clients must:

  • Know the address and API of every individual service (tight coupling to service topology).
  • Make multiple round trips to gather data from several services (especially costly for mobile networks).
  • Handle cross-cutting concerns (auth, rate limiting, logging) themselves, or each service must re-implement them.
  • Deal with service refactoring by updating every client.
  • Manage protocol diversity — backend services may use non-standard protocols.
  • Face an expanded attack surface from publicly exposed service endpoints.

As microservices.io states: clients face a “granularity mismatch” — microservices expose fine-grained APIs, but clients need coarser-grained functionality.

Solution

An API Gateway acts as the single front door for all clients. It receives external requests, applies cross-cutting policies, and routes them to the appropriate backend services. Clients interact only with the gateway; backend services can change independently. The gateway handles requests through simple routing (reverse proxy) or request fanning (aggregating multiple service calls).

         ┌────────────┐
Clients ──► API Gateway├──► Order Service
         │            ├──► Product Service
         │            └──► Auth Service
         └────────────┘

Core Responsibilities

Three primary design patterns within the API Gateway (Microsoft):

PatternDescription
Gateway RoutingReverse proxy: route client requests to different services using layer-7 routing. Decouples clients from service topology.
Gateway AggregationFan out a single client request to multiple services; aggregate results into one response. Reduces chattiness.
Gateway OffloadingCentralize cross-cutting concerns so individual services don’t implement them.

Offloadable concerns:

  • SSL/TLS termination and mutual TLS
  • Authentication and authorization (JWT, OAuth)
  • Rate limiting and throttling
  • IP allowlist/blocklist
  • Logging, monitoring, and distributed tracing
  • Response caching
  • Web application firewall (WAF)
  • GZIP compression
  • Static content serving

API Gateway vs. Service Mesh

API GatewayService Mesh
TrafficNorth-south (external to internal)East-west (service to service)
ConcernClient-facing API managementInternal service communication
LocationEdge of the cluster/systemEvery service instance
Complementary?Yes — they serve different layers

Backend for Frontend (BFF) Variant

Rather than one universal gateway, the BFF approach creates separate API Gateways optimized for each client type (web, mobile, partner API). Each BFF is a thin layer that aggregates and tailors responses for its specific client. This eliminates the “one-size-fits-all” compromise.

  • Kong — open-source, plugin-based, high performance.
  • AWS API Gateway — managed cloud service.
  • Azure API Management — enterprise-grade, full lifecycle management.
  • Azure Application Gateway — managed load balancer with layer-7 routing and WAF.
  • Ocelot — .NET-specific, lightweight.
  • Envoy / Ambassador / Istio ingress — cloud-native proxies with gateway capabilities.
  • Nginx / HAProxy — open-source reverse proxies with gateway features.

When to Use

  • Microservices architectures with multiple client types.
  • When cross-cutting concerns must be centralized.
  • When you need protocol translation between clients and services.
  • When you want to decouple client contracts from service implementations.
  • When a single operation requires calls to multiple services (use aggregation).

Not suitable when:

  • Simple, monolithic applications with a single API.
  • The gateway itself becomes a development bottleneck (single team owns all routes).

Trade-offs

BenefitDrawback
Single entry point simplifies clientsPotential single point of failure (mitigated with HA deployment)
Centralizes auth, rate limiting, loggingCan become an unscalable bottleneck if poorly designed
Clients are decoupled from service topologyGateway team becomes a dependency for all service changes
Enables protocol translationAdded network hop may increase latency (typically insignificant)
Reduces client round trips via aggregationImplementation requires careful scalability (reactive/event-driven approaches)
Reduces attack surfaceRouting rules must be kept synchronized with actual service changes

Graph View

Backlinks