An API gateway is a single entry point for client requests to your APIs. Instead of the client talking to many services (auth, users, orders, notifications), it talks to the gateway; the gateway routes the request to the right backend (or aggregates several backends) and returns a response. The client sees one host and one API; the gateway hides the internal topology.

Typical responsibilities: routing (e.g. /users → user service, /orders → order service), auth (validate JWT or API key before forwarding), rate limiting, request/response transformation, and aggregation (e.g. one request that calls multiple services and combines results—BFF pattern).

Use a gateway when: you have multiple backends and want one URL and one place for cross-cutting concerns (auth, rate limit, logging); you want to version or deprecate APIs without changing every client; or you need aggregation (e.g. mobile app needs one call that returns user + settings + notifications). For a single backend or a simple full stack app, a gateway can be overkill—your backend can do auth and routing itself.

BFF (Backend for Frontend): A variant is a thin backend per client type (e.g. "BFF for web," "BFF for mobile") that aggregates and shapes data for that client. The BFF talks to internal services; the client talks only to the BFF.

Implementation: You can use a managed gateway (AWS API Gateway, Kong, Apigee) or a custom service (Node, Go) that proxies and applies middleware. The gateway should be stateless so it can scale horizontally; auth and rate limits often use a shared store (Redis). Monitoring: Log request/response at the gateway (sanitized) for debugging and analytics; measure latency per route and error rates. Because all traffic flows through the gateway, it is a natural place for distributed tracing and access logs.