communication

API Gateway

A single ingress for clients — routing, auth, rate limiting, response shaping — in front of N internal services.

If external clients talked directly to dozens of internal microservices, every client would need to know each service's location, handle authentication for each, and cope with the internal topology — and every service would have to re-implement cross-cutting concerns like auth and rate limiting. An API gateway solves this by being the single front door: one entry point that sits in front of all the services and handles the concerns that would otherwise be duplicated everywhere.

A hotel front desk: guests make one request at reception, which routes it to housekeeping, the kitchen, or concierge — they never wander the back corridors themselves.

Key Concepts

1
The gateway routes incoming requests to the appropriate backend service based on the path or host, so clients see one stable API surface while the internal decomposition stays hidden and free to change. Along the way it concentrates the cross-cutting work: authenticating and validating tokens once at the edge, enforcing rate limits, terminating TLS, logging and collecting metrics, and sometimes transforming or aggregating responses. A related idea is the Backend-for-Frontend pattern, where you run a tailored gateway per client type — one shaped for the mobile app, another for the web — so each gets exactly the data shape and aggregation it needs rather than a one-size-fits-all API. By centralising these concerns, individual services can stay focused on business logic and trust that the request reaching them has already been authenticated and throttled.
2
The trade-offs interviewers want acknowledged are that the gateway is a potential single point of failure and a performance bottleneck, so it must be made highly available and kept fast, and that it can become a "god component" if too much business logic creeps into it — routing, auth, and shaping belong there, but domain logic does not. It is also worth distinguishing the gateway (north-south traffic, client-to-system) from a service mesh (east-west traffic, service-to-service), since the two are complementary rather than competing.