A gateway solves edge concerns, not bad APIs
An API Gateway is valuable when many clients and services need shared edge policies such as authentication handoff, TLS termination, rate limits, routing, request size limits, and observability. It is not a substitute for service authorization, domain validation, or coherent API design.
Signals that justify a gateway
- Put cross-cutting transport policy at the gateway; keep business policy in services.
- A gateway can route versions and channels, but service contracts remain owned by services.
- Rate limiting should identify the correct actor or tenant, not only source IP.
- Gateway retries must be disabled or carefully bounded for unsafe mutations.
- High availability and configuration delivery become production responsibilities once the gateway is critical.
Decision path at the edge
Edge policies stop before domain authorization. A request that passes gateway authentication must still be authorized against the target resource by the service.
Should this responsibility live at the gateway?
Edge policies stop before domain authorization. A request that passes gateway authentication must still be authorized against the target resource by the service.
Client
Introducing a gateway for multiple channels
When the gateway becomes harmful
Gateway decision checklist
- List duplicated edge concerns across services first.
- Keep resource authorization in the backend.
- Define rate-limit identity and budgets.
- Treat gateway config as versioned deployable code.
- Test gateway outage and bypass assumptions.