A developer platform's API gateway has accumulated business logic and become a bottleneck for every team. What should be moved out, and what belongs there?

What belongs at the gateway

Everything decidable from the request alone, and everything whose purpose is to reject before backend capacity is consumed:

• Authentication, establishing identity once so services receive an authenticated principal.
• Coarse rate limiting and quotas — the entire point is rejecting excess before it reaches services, so a limiter behind the expensive work is decoration.
• Request validation and size limits.
• Routing, versioning and deprecation headers.
• TLS termination and transport policy.
• Observability and attribution, tagging every request with account, endpoint and version.

What should be moved out

Business logic, in every form. A gateway holding pricing rules, eligibility checks or workflow becomes a distributed monolith every team must change and nobody owns — which is exactly the bottleneck described.

Fine-grained authorisation. Whether this account may access this specific resource needs domain state the gateway does not have. The gateway establishes who; the service decides what they may do — and at the data access layer, so a new endpoint cannot forget.

Idempotency. The key must be recorded in the same transaction as the effect it protects, and the gateway does not participate in that transaction. Implemented there, the system is usually idempotent and occasionally not, which for this property is the same as not.

Response composition across services, which couples the gateway to every service's model. If a client needs a composed response, that is a backend-for-frontend concern owned by the client team.

Data transformation specific to one consumer, for the same reason.

The structural fix

A thin gateway plus per-experience backends. The gateway does the cross-cutting, request-decidable work; each client team owns a backend-for-frontend shaping responses for its own surface.

That removes the bottleneck by giving each team a place to put consumer-specific logic that they own and deploy, rather than queueing behind a shared component.

The test for anything proposed at the gateway

Can this be decided from the request alone, and is it the same for every consumer? If either answer is no, it belongs elsewhere — and gateways become bottlenecks precisely by accumulating things that fail this test.