Skip to content

API Gateway#

Problem statement (interviewer prompt)

Design a single entry point that fronts dozens of internal microservices for external clients. It must handle TLS termination, authentication, rate limiting, request routing by host/path, response aggregation, and surface a consistent API contract - all with <5ms p99 added latency.

A single entry point that fronts internal services, handling auth, rate limiting and routing.

flowchart LR
  C([Client])
  GW[API Gateway]
  S1([User Service])
  S2[Order Service]
  S3[Payment Service]
  C --> GW
  GW --> S1
  GW --> S2
  GW --> S3

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class C,S1 client;
    class GW edge;
    class S2,S3 service;
flowchart TB
  subgraph Clients
    Web([Web SPA])
    Mob([Mobile])
    Part([Partner / B2B])
  end

  subgraph Edge
    DNS[DNS]
    LB[L4/L7 LB]
  end

  subgraph Gateway[API Gateway Cluster]
    direction TB
    TLS[TLS termination]
    AUTHN[AuthN<br/>JWT / OAuth2 / mTLS]
    AUTHZ[AuthZ / RBAC]
    RL[Rate Limiter<br/>token bucket per key]
    QUOTA[Quota / Plans]
    RT[Router<br/>host / path / header]
    TX[Request transform<br/>protocol bridging REST↔gRPC]
    AGG[Response aggregation<br/>BFF / GraphQL]
    CACHE[(Response cache)]
    RETRY[Retry / Timeout /<br/>Circuit breaker]
    WAF[WAF / Bot]
    LOG[Access log + tracing]
  end

  subgraph Control[Control Plane]
    REG[Service Registry<br/>Consul / xDS]
    CFG[Config / Routes]
    SECRETS[Secrets / Keys / JWKS]
    POLICY[Policy Store - OPA]
    AN[Analytics / Billing]
  end

  subgraph Backend[Internal Services]
    S1([User])
    S2[Order]
    S3[Payment]
    S4[Search - gRPC]
    S5[Legacy SOAP]
  end

  Web --> DNS --> LB --> TLS
  Mob --> DNS
  Part --> DNS
  TLS --> WAF --> AUTHN --> AUTHZ --> RL --> QUOTA --> RT
  RT --> TX --> CACHE
  CACHE -->|miss| RETRY
  RETRY --> S1
  RETRY --> S2
  RETRY --> S3
  RETRY --> S4
  RETRY --> S5
  RETRY --> AGG
  AGG --> Web
  REG -.discovery.-> RT
  CFG -.routes.-> RT
  SECRETS -.keys.-> AUTHN
  POLICY -.rules.-> AUTHZ
  Gateway -.metrics.-> AN
  Gateway -.logs.-> LOG

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class Web,Mob,Part,S1 client;
    class DNS,LB,TLS,WAF edge;
    class AUTHN,AUTHZ,QUOTA,RT,TX,AGG,RETRY,LOG,REG,CFG,SECRETS,POLICY,AN,S2,S3,S4,S5 service;
    class CACHE cache;
    class RL storage;

Cross-cutting concerns#

  • AuthN: validate JWT (JWKS rotation), opaque tokens via introspection, mTLS for B2B.
  • Rate limit: per-API-key, per-IP, per-route; token bucket in Redis.
  • Transform: REST→gRPC, batch requests, GraphQL gateway / BFF.
  • Observability: trace ID propagation (W3C traceparent), structured logs.

Deployment#

  • Active-active cluster behind a L4 LB.
  • Hot reload of routes (xDS or pull from Git).
  • Blue/green or canary by route weight.

Glossary & fundamentals#

Concepts referenced in this design. Each row links to its canonical page; the tag column shows whether it is a high-level (HLD) or low-level (LLD) concept.

Tag Concept What it is Page
HLD Load balancer / GSLB L4/L7 traffic distribution and failover load-balancer
HLD API gateway / BFF single ingress, auth, rate limit, routing api-gateway
HLD Idempotency & retries safe re-execution, backoff + jitter idempotency-retries
HLD Resilience patterns timeout, retry, breaker, bulkhead, backpressure resilience-patterns
HLD Observability metrics, logs, traces, SLOs observability
HLD Service mesh sidecar mesh, mTLS, traffic policy service-mesh
HLD Multi-region & DR RTO / RPO, active-active, failover multi-region-dr
LLD REST API design verbs, statuses, pagination, errors rest-api-design

Quick reference#

Functional requirements#

  • Single ingress for external traffic.
  • AuthN/AuthZ, rate limit, quota, request/response transform.
  • Routing by host/path/header/version.
  • Aggregation (BFF) for chatty clients.
  • Protocol bridging (REST ↔ gRPC, WS).

Non-functional#

  • Latency overhead < 5 ms p99.
  • 10-100k RPS per node.
  • 99.99% availability.

Capacity estimation#

  • 50k RPS, 4 KB req → 200 MB/s.
  • JWT verify: ~10-50 µs (RS256 with cached JWKS).

API surface#

  • Public: gateway IS the API; OpenAPI spec defines routes.
  • Admin: POST /routes, POST /consumers, POST /plugins.

Data model#

  • Route{ id, hosts, paths, methods, service_id, plugins[] }
  • Service{ id, upstream, retry, timeout }
  • Consumer{ id, credentials[], plan_id }
  • Plan{ id, quota, rate_limit }

Trade-offs#

  • One big gateway vs BFF-per-client: one gateway is simpler ops; BFFs decouple clients but multiply infra.
  • Smart vs dumb gateway: too much logic at gateway = god component; keep business logic in services.
  • Sidecar mesh vs gateway: ingress gateway + service mesh (Istio/Linkerd) for east-west - overlap, decide boundary.

Real-world refs#

  • Kong, Tyk, Apigee, AWS API Gateway, Envoy + Istio, NGINX, Spring Cloud Gateway.

FAQ#

What is an API gateway and why use one?#

An API gateway is a single entry point that fronts internal microservices and handles TLS termination, authentication, rate limiting, routing, and aggregation, so clients see one consistent API.

What is the difference between an API gateway and a load balancer?#

A load balancer distributes traffic across replicas of the same service at L4 or L7. An API gateway adds protocol awareness like auth, rate limiting, request transformation, and per-route routing across many services.

Is an API gateway a single point of failure?#

It can be, so production gateways run as a horizontally scaled fleet behind a load balancer with multi-AZ replicas and health checks. The control plane is separated from the data plane to avoid coupling.

Kong, Envoy, AWS API Gateway, Apigee, Tyk, and NGINX with the Plus or OSS modules are common. Cloud-native deployments often pair Envoy or Istio with a thin gateway layer for external traffic.

How does an API gateway handle authentication?#

It terminates TLS, validates the bearer token or API key, and forwards a trusted identity header to downstream services. JWT verification and OAuth introspection are the two common flows.

  • Service Mesh: service meshes complement API gateways for internal service-to-service communication
  • Load Balancer: load balancers operate at L4/L7 and often pair with API gateways for traffic distribution
  • CDN: CDNs can front an API gateway to cache responses and reduce origin load

Further reading#

Curated, high-credibility sources for going deeper on this topic.

Video walkthrough

Reverse Proxy vs API Gateway vs Load Balancer : via ByteByteGo