API Gateway

What it is

An API gateway is a single ingress for clients (web, mobile, partners) that handles cross-cutting concerns: authentication, authorization, rate limiting, routing to internal services, request/response shaping, sometimes TLS termination and observability.

  Mobile app --> API Gateway --> service A
                             --> service B
                             --> service C

Concerns

Auth: validate JWT/OAuth tokens, API keys, mTLS for partners; optional token exchange at edge.
Rate limit: protect backends from abuse (see rate-limiter); per-user and per-API-key quotas.
Routing: path-based or host-based route tables; A/B and canary traffic splits.
BFF (Backend for Frontend): sometimes a per-client-type gateway or thin service shapes aggregated responses for mobile vs web—avoids one generic API for all clients; tradeoff is more gateway logic to maintain.

When to use

Many public clients and microservices behind the gateway.
Central place for policy (auth, limits, CORS, IP allowlists).
Single DNS and certificate management for consumers.

Alternatives

Service mesh (mTLS, retries) inside the cluster without replacing edge auth—often gateway + mesh together.
Direct to services with each service doing auth: duplication and drift.
CDN + Lambda@Edge for very edge-heavy auth/limiting—different operational model.

Failure modes

Gateway as bottleneck: must scale horizontally and cache JWKS public keys.
Misrouting: bad config sends traffic to wrong cluster/version.
Large payloads through gateway: memory and timeout limits; sometimes direct upload to blob-storage with signed URLs.

Interview talking points

Separate edge security from service-level authorization (what user can do vs which microservice enforces domain rules).
Mention observability: correlation ids through gateway to all services.
Tie limits and timeouts to latency-throughput SLOs and back-of-envelope capacity.

On this page