Command Palette

Search for a command to run...

PHASE 12Advanced ~7 min· topic 25 of 39Level 5

System 12.25 — API Gateway (HLD)

In one line

The gateway as a product: routing, auth, quotas, rate limiting, observability — scaled and made boring.

0/39 · 0%

Think of it like this

The single front-desk idea from Phase 9, run at the scale of an entire company's traffic, with its own team, its own dashboard, and rules that can be changed without redeploying every other service.

Key ideas

  1. 01

    Built on 9.7: routes, policies, plugins. The HLD adds: multi-region, hot-standby, config-driven routing from a control plane.

  2. 02

    Control plane vs data plane: config pushed from a control service to gateway nodes (data plane) — config propagation is a real subsystem.

  3. 03

    Auth at the edge: JWT validation (public key cache), OAuth2 introspection, API keys, per-tenant quoting — all cache-friendly.

  4. 04

    Rate limiting at the edge: Redis-backed (12.2), per-tenant/endpoint; global vs regional counters.

  5. 05

    Observability: every request → metrics (RED), logs (traceId), traces — the edge is the best place to measure the pact.

  6. 06

    Scaling: gateways are stateless → autoscale; each node holds its Redis limiter shard view + config snapshot.

  7. 07

    Failures: gateway crash → clients retry to other nodes (DNS/LB health check); config push failure → nodes keep last-good config.

  8. 08

    Interview: gateways must be BORING — the talk is about the control plane, config propagation, and edge policies.

Code & diagrams

GatewayControlPlanediagram

The gateway nodes (data plane) just enforce rules; a separate control plane is where the rules actually live and get edited.

Rendering diagram…

Explain without notes

01

A bad route config is pushed and gateways start 503ing. What keeps them serving while config is rolled back?

Practice

01

Design the config model (routes, quotas, plugins) and its push + last-good fallback flow.

Trade-offs

  • ↔

    Policy richness at the edge vs per-request cost — keep flat auth + quota, push anything fancy downstream.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Completion checklist

  • I can present the gateway as control/data plane service with config propagation and failure fallback.

Back to phase