API Gateway Patterns

API gateway: sits between clients and backend services. Cross-cutting concerns: Authentication/Authorization: validate JWT, API key, or OAuth token before routing. Service receives pre-validated request. Rate limiting: enforce per-client or per-endpoint request limits. Return 429. TLS termination: decrypt HTTPS at the gateway; internal traffic may be HTTP or mTLS. Request/response transformation: add headers, mask sensitive fields, translate protocols (REST→gRPC). Load balancing: round-robin or weighted distribution to backend instances. Caching: cache GET responses at the gateway. Logging and tracing: emit access logs and start a trace span for every request. Tools: AWS API Gateway, Kong, Nginx, Envoy, Traefik, Apigee.

BFF (Backend for Frontend): coined by Sam Newman. Problem: one generic API serving web and mobile gives web too much data (over-fetching) and mobile too little structure. Solution: separate BFF per client type. Web BFF: aggregates, enriches, formats data for rich desktop experience. Mobile iOS BFF: returns compact payloads optimized for mobile bandwidth and screen size. Mobile Android BFF: similar, may differ in field naming or structure. Benefits: each frontend team owns its BFF; changes to mobile API don't affect web; server-side aggregation reduces mobile round trips. Trade-off: code duplication across BFFs; use shared libraries for common logic. GraphQL as BFF: single GraphQL endpoint that each client queries selectively is a popular alternative.

Rate limiting: algorithms: Token bucket: client has a bucket of tokens; each request consumes one. Tokens replenish at a fixed rate. Allows bursts up to bucket size. Leaky bucket: requests processed at fixed rate regardless of burst. Smooths traffic. Fixed window: count requests per minute window. Vulnerable to boundary abuse (burst at window edge). Sliding window: rolling time window. More accurate. Response: HTTP 429 Too Many Requests. Retry-After header indicates when to try again. Rate limit dimensions: per API key, per IP, per user ID, per endpoint. Distributed rate limiting: requires shared counter in Redis across gateway instances. Libraries: rate-limiter-flexible (Node.js), bucket4j (Java), slowapi (Python).

Authentication at gateway: validates the credential. JWT: verify signature (RS256/ES256), check exp, iss, aud claims. API key: lookup in key store, check if active. OAuth2 token introspection: call authorization server to validate opaque token. mTLS: verify client certificate. After validation: inject user context (user ID, roles, tenant ID) into upstream headers for services to consume without re-validating the token. Authorization at gateway: coarse-grained — "authenticated users may call /api/v2/*, unauthenticated users get 401". Fine-grained authorization (can user X access resource Y?) typically happens in the service, where business context is available. OPA (Open Policy Agent) as gateway plugin: policy-as-code authorization at the gateway layer.

API versioning strategies: URL path: /api/v1/users, /api/v2/users. Most visible, most common. Easy to route at gateway. Header: Accept: application/vnd.api+json;version=2. Clean URLs but less discoverable. Query parameter: /api/users?version=2. Easy to test in browser, less RESTful. Content negotiation: Accept: application/vnd.company.v2+json. Most REST-correct. Gateway routing: route /v1 requests to v1 cluster, /v2 to v2 cluster. Enables running both versions simultaneously. Deprecation: announce sunset date in Sunset and Deprecation response headers (RFC 8594). Log which clients still use deprecated versions. Semantic versioning for APIs: breaking changes (removing fields, changing types) → major version. Additive changes (new optional fields) → no new version needed. Backward-compatible changes should not require versioning.