api-gateway-patternlisted

# API gateway pattern A gateway is the single front door to many services, handling the concerns every client needs and no service should reimplement: routing, auth, rate limiting, TLS. Its failure mode is scope creep: the moment business logic leaks in, the gateway becomes a monolith every team must coordinate through. ## Method 1. **Put edge cross-cutting concerns in the gateway.** TLS termination, authentication (verify the token, pass identity downstream: see authn-design, jwt-handling), rate limiting (see rate-limiting), request routing, and common observability (see distributed-tracing's entry span): the things every request needs and every service would otherwise duplicate inconsistently. 2. **Keep business logic out, ruthlessly.** The gateway routes and enforces; it does not know that an order over $1000 needs approval: that is a service's job. Business rules in the gateway recreate the distributed monolith's coupling at the edge, where every team's change now waits on the gateway team (see microservices-boundaries' coupling warning). 3. **Use the BFF variant for divergent clients.** When a mobile app, web SPA, and partner API need genuinely different shapes (payload size, aggregation, chattiness: see mobile-performance vs a data-rich desktop UI), a Backend-for-Frontend per client type does the client-specific aggregation and shaping: owned by the client team, not a shared gateway. This keeps client-driven ch