API gateway limits and request transformation

Gateways enforce per-consumer quotas, burst limits, and concurrency caps — often keyed by API key, JWT `sub`, or tenant. Return 429 with `Retry-After` and structured error bodies.

Transforms adapt protocols and contracts at the edge: strip internal headers, map v1 paths to v2 services, validate JSON schema before origin, translate REST to gRPC, or inject correlation IDs.

					# Illustrative policy shape
routes:
  - path: /v1/orders/*
    rewrite: /v2/orders/*
    rate_limit: 1000/minute
    consumer_key: $header.X-Api-Key
				

Backward-compatible migrations keep old clients on gateway aliases while services consolidate implementations.

On interviews: idempotency for retried requests through transforms; schema validation failures as 400 at edge; avoiding gateway as hidden business rules engine.

Common pitfalls: transforms that change semantics silently; rate limits that starve one tenant's noisy neighbor; validation diverging from origin schemas.

The trade-off is balancing simplicity, performance, safety, and operability — name which axis you optimized and what cost you accepted.

Checklist:

• Key limits by consumer and route class.
• Document rewrite rules and deprecation windows.
• Validate payloads once — gateway or origin, not inconsistently.
• Measure 429 rates per API consumer.