What belongs in an API gateway?

A gateway owns edge concerns that are the same for every service: TLS termination, authentication (validate the token, forward identity), rate limiting per client, routing, request logging and trace-id injection, basic transformation (headers, protocol translation such as REST to gRPC), and coarse-grained caching. These are cross-cutting, change rarely, and benefit from one enforcement point.

It must not own business logic or orchestration: no "if the customer is premium, call Pricing then Discounts". As soon as it aggregates data with rules, every feature touches the gateway, every team deploys it, and it becomes a shared bottleneck with a p99 that grows with every rule — the gateway becomes the monolith. Client-specific aggregation belongs in a Backend-for-Frontend owned by the client team, which can compose service calls for that screen without becoming a shared chokepoint.

It is a single point of failure by construction, so it runs as a stateless fleet behind DNS or anycast with health checks, with its configuration versioned and deployed like code, and with its own timeouts and breakers per upstream so a slow service does not exhaust gateway connections.