Back to All Concepts
MicroservicesSecurityInfrastructureBeginner

API Gateway Pattern

The single entry point for microservices. Implementing rate limiting, authentication, and protocol translation/aggregation.

The Front Door of Microservices

In a monolithic architecture, client requests go directly to the application. In a Microservices Architecture, your system might be split into 50+ different services. You cannot expect a mobile app to know the IP address of every service, handle authentication for each, and aggregate data from three different places.

The API Gateway is a server that acts as a single entry point into the system. It encapsulates the internal system architecture and provides an API that is tailored to each client.

1. Core Responsibilities

An API Gateway is more than just a reverse proxy. It handles cross-cutting concerns:

  1. Routing: The most basic function. GET /users -> User Service. GET /orders -> Order Service.
  2. Aggregation: A client needs user details AND their recent orders. The Gateway calls both services and combines the JSON into one response, saving the client from making 2 network calls (which is expensive on mobile).
  3. Protocol Translation: The outside world speaks HTTP/JSON. Internal microservices might use gRPC (binary, fast) or AMQP (messaging). The Gateway translates between them.
  4. Offloading: Moving functionality from individual services to the gateway:
    • SSL Termination
    • Authentication / Authorization
    • Rate Limiting
    • Caching

2. The BFF Pattern (Backend for Frontend)

A single API Gateway can become a bottleneck or a "God Class" that knows too much. The BFF Pattern suggests creating a separate gateway for each client interface.

  • Mobile API Gateway: Small payloads, excludes heavy data to save battery.
  • Web API Gateway: Rich payloads for desktop screens.
  • Public Partner API: Strict rate limits and OAuth scope enforcement.

3. Rate Limiting Algorithms

Protecting your services from overuse or DDoS is critical. The Gateway typically implements this using Redis.

A. Token Bucket

  • Imagine a bucket that holds NN tokens.
  • Tokens stream in at rate rr per second.
  • To make a request, a client must take a token.
  • Pros: Allows bursts of traffic (up to bucket size).
  • Cons: slightly complex to implement.

B. Leaky Bucket

  • Requests enter a queue (bucket) and are processed at a constant rate.
  • If the queue is full, new requests are dropped.
  • Pros: Smoothes out traffic bursts exactly.
  • Cons: Data burstiness is lost; valid traffic might be dropped during short bursts.

C. Fixed Window

  • "100 requests per minute".
  • Reset counter at 12:00, 12:01, etc.
  • Problem: A client can send 100 requests at 11:59:59 and another 100 at 12:00:01. The server receives 200 requests in 2 seconds.

D. Sliding Window Log

  • Keep a timestamp log of every request.
  • Expensive memorywise but perfectly accurate.

4. Authentication & Security

The API Gateway is the Policy Enforcement Point.

  1. Authentication: The client sends a JWT or API Key. The Gateway validates the signature (Is this key valid?).
  2. Authorization: The Gateway checks scopes (Can this key access /admin?).
  3. Forwarding: If valid, the Gateway passes the request to the microservice. It often injects headers:
    • X-User-Id: 12345
    • X-Role: Admin So internal services don't need to re-validate tokens; they trust the Gateway.

5. Potential Drawbacks

While essential, API Gateways introduce risks:

  • Single Point of Failure: If the Gateway acts up, the entire system is down. It requires high-availability setup (load balancers in front of redundant gateways).
  • Latency: It adds an extra hop. However, 1 hop on a high-speed internal network is usually cheaper than multiple round-trips from the client to separate services.
  • Complexity: Configuring routes and policies for hundreds of microservices is a management burden.

6. Popular Technologies

  • Nginx / HAProxy: The raw, high-performance base layers. Hard to configure for complex logic.
  • Kong: Built on Nginx, adds plugins for Auth, Rate Limiting, Logging. Very popular open-source choice.
  • Amazon API Gateway: Serverless, scales infinitely, pays per request.
  • Netflix Zuul: The original Java-based gateway from Netflix.
  • GraphQL Servers (Apollo): Can act as an API Gateway, specifically excellent for Data Aggregation (Federation).

Summary

The API Gateway is the receptionist of your distributed system.

CapabilityDescription
Routing/api/v1/* -> Microservice
SecuritySSL termination + JWT Validation
TrafficRate Limiting + Circuit Breaking
TranslationHTTP -> gRPC

About ScaleWiki

ScaleWiki is an interactive educational platform dedicated to demystifying distributed systems, software architecture, and system design. Our mission is to provide high-quality, technically accurate resources for software engineers preparing for interviews or solving complex scaling challenges in production.

Read more about our Editorial Guidelines & Authorship.

Educational Disclaimer: The architectural patterns and system designs discussed in this article are based on common industry practices, technical whitepapers, and public engineering blogs. Actual implementations in enterprise environments may vary significantly based on specific product requirements, legacy constraints, and evolving technologies.

Related Articles