API Gateway — Notes

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.