System Design · Architecture under constraints
What does an API gateway do and what risks does it introduce?
Short answer
An API gateway is the single entry point for clients, handling routing, authentication, rate limits, TLS and observability. It can become a bottleneck, a single point of failure or a hidden monolith.
An API gateway sits in front of backend services and gives clients one stable interface. It routes requests by path or host, terminates TLS, validates tokens, applies quotas, transforms headers and emits metrics. Without it, every client would need to know every service and repeat the same cross-cutting logic.
Typical responsibilities
- Routing and versioning so internal services can move without breaking clients
- Authentication and authorization enforcement at the edge
- Rate limiting and request size limits per client or API key
- TLS termination, CORS and response compression
- Retries, timeouts and circuit breaking for upstream calls
- Access logs, traces and request-level metrics
A gateway is not the same as a load balancer. A load balancer distributes connections; a gateway understands APIs and applies policy. Many deployments combine both, with a layer 4 balancer in front of a gateway fleet. The gateway itself must be horizontally scaled and its configuration must be highly available.
The risks are concentration and coupling. If the gateway is down, every API is down. If every team adds bespoke logic to it, it becomes a distributed monolith with a shared release cycle. Keep it to cross-cutting policy, push domain logic into services, and give teams a self-service route configuration with validation.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How is an API gateway different from a load balancer?
- 2How do you prevent the gateway from becoming a monolith?
- 3Should the gateway retry failed requests?
- 4How do you deploy gateway configuration safely?
Say it in the interview
An API gateway gives clients one entry point and centralizes routing, auth, quotas and telemetry. It is different from a load balancer because it understands APIs and applies policy. The main risks are that it becomes a single point of failure or accumulates domain logic and turns into a monolith. I keep it to cross-cutting concerns, scale it horizontally, and make retries conditional on idempotency.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.