An API platform serving millions of external developers must place authentication, rate limiting, quotas, retries, idempotency and tenant isolation. Which belong at the gateway and which must live deeper?

At the gateway

Authentication. Verify the credential and establish identity once, at the edge. Every service behind it receives an authenticated principal rather than re-implementing verification. Rejecting an invalid credential should be the cheapest possible operation.

Coarse rate limiting and quota enforcement. Per-account request rates, concurrency ceilings, burst allowances. This must be at the edge, because the entire point is to reject excess load before it consumes backend capacity. A rate limiter behind the expensive work is decoration.

Request validation and size limits. Malformed or oversized requests should never reach a service.

Routing, versioning and deprecation handling. Which backend serves this API version, and what warning headers a deprecated endpoint carries.

Observability and attribution. Every request tagged with account, endpoint and version — the raw material for capacity planning, billing and customer support.

Deeper in the system

Idempotency. This is the one that most often gets misplaced. An idempotency key must be recorded in the same transaction as the effect it protects. A gateway can deduplicate concurrent in-flight requests, but it cannot guarantee that the key and the side effect commit atomically, because it does not participate in the service's transaction. Implement it at the gateway and you get a system that is usually idempotent and occasionally sends two messages, which is worse than not claiming the property.

Fine-grained authorisation. Whether this account may access this specific resource requires domain knowledge and data the gateway does not have. The gateway establishes who; the service decides what they may do.

Retries to downstream dependencies. The gateway can retry idempotent requests, but retry policy toward internal dependencies belongs with the service that understands what is safe to retry and what its deadline budget is.

Per-tenant workload isolation. The gateway can throttle a tenant; it cannot stop one tenant's queries from consuming a shared connection pool or evicting another's cache entries. That requires bulkheads at the resource — partitioned pools, fair queueing, per-tenant quotas on shared stores.

The webhook direction, which is where platforms actually get hurt

Outbound delivery to customer endpoints is the harder half, because the platform does not control the recipient. It needs: retries with exponential backoff and jitter; a delivery attempt log; signed payloads so recipients can verify authenticity; an event id so customers can deduplicate, since at-least-once is the only honest guarantee; per-destination circuit breaking so one customer's dead endpoint does not consume the delivery fleet; and a dead-letter path with visibility so customers can replay what they missed.

The contract to publish is precise: at-least-once delivery, no ordering guarantee across events, and here is the id to deduplicate on. Implying ordering or exactly-once is the fastest way to have customers build on a guarantee you cannot keep.

The principle

The gateway enforces what can be decided from the request alone; everything requiring domain state or transactional atomicity lives with the service that owns the data. Misplacing idempotency is the most common and most expensive violation of that rule.