What Is the API Gateway Pattern?
Learn what an API gateway is, how it routes requests, and how it centralizes auth, rate limiting, and logging.
Expected Interview Answer
An API gateway is a single entry point that sits in front of a set of backend services, routing each incoming request to the right service while centrally handling cross-cutting concerns like auth, rate limiting, logging, and request/response transformation.
Rather than every client discovering and calling each microservice directly, all traffic flows through the gateway, which inspects the request, applies policies such as authentication and rate limiting once, and forwards it to the appropriate downstream service, often aggregating multiple service calls into one response when needed. This centralizes concerns that would otherwise be duplicated in every service — TLS termination, request logging, throttling, API key validation — and gives operators one place to monitor and control traffic. Unlike a BFF, which is tailored to one specific client type, a general-purpose gateway usually serves all clients with a broadly similar contract, though many real systems combine both: a gateway for cross-cutting policy plus BFFs behind it for client-specific shaping. The main risk is that the gateway becomes a single point of failure and a performance bottleneck if not built for high availability and horizontal scaling.
- Single entry point simplifies client-side service discovery
- Centralizes auth, rate limiting, and logging instead of duplicating per service
- Can aggregate multiple service calls into one response when needed
- Provides one place to apply traffic policies and observability across all services
AI Mentor Explanation
An API gateway is like the single entrance gate of a stadium where every fan is checked once for a valid ticket and bag policy before being directed to their specific stand. Instead of each stand having its own separate security check, the gate handles it centrally for everyone entering. The gate staff also route fans to the correct stand based on their ticket type. That single-checkpoint-then-route model is exactly what an API gateway does for requests hitting multiple backend services.
Step-by-Step Explanation
Step 1
Client sends one request to the gateway
All external traffic enters through a single, well-known gateway endpoint instead of hitting services directly.
Step 2
Gateway applies cross-cutting policies
Auth, rate limiting, and logging happen once at the gateway rather than being duplicated per service.
Step 3
Gateway routes to the correct service
Based on the request path or content, the gateway forwards it to the appropriate downstream microservice.
Step 4
Response returned (optionally aggregated)
The gateway can combine multiple service responses into one payload before returning it to the client.
What Interviewer Expects
- Understanding of the gateway as a single entry point centralizing cross-cutting concerns
- Ability to contrast a general-purpose gateway with a client-specific BFF
- Awareness that the gateway can become a single point of failure without HA design
- Mention of concrete policies handled at the gateway: auth, rate limiting, logging
Common Mistakes
- Confusing an API gateway with a BFF, which is tailored to one client type
- Not addressing the single-point-of-failure risk and how to mitigate it
- Assuming the gateway must always aggregate responses, when routing alone is often enough
- Forgetting that duplicated per-service auth logic is exactly what the gateway is meant to remove
Best Answer (HR Friendly)
“An API gateway is a single front door that all requests go through before reaching the actual backend services. It checks things like who you are and how many requests you are allowed to make in one place, then sends the request to the right service, so each individual service does not have to repeat that same logic.”
Code Example
const routes = {
'/api/users': 'https://user.svc.internal',
'/api/orders': 'https://order.svc.internal',
}
app.use(async (req, res, next) => {
if (!isAuthenticated(req)) return res.status(401).json({ error: 'Unauthorized' })
if (isRateLimited(req.ip)) return res.status(429).json({ error: 'Too many requests' })
next()
})
app.use('/api/:service', async (req, res) => {
const target = routes[`/api/${req.params.service}`]
if (!target) return res.status(404).json({ error: 'Unknown service' })
const upstream = await fetch(target + req.url, { headers: req.headers })
res.status(upstream.status).json(await upstream.json())
})Follow-up Questions
- How would you keep an API gateway from becoming a single point of failure?
- How does an API gateway differ from a load balancer?
- When would you combine a gateway with per-client BFFs rather than choosing just one?
- How would you handle service discovery in a gateway as microservices scale?
MCQ Practice
1. What is the main role of an API gateway?
An API gateway centralizes auth, rate limiting, and routing in front of backend services.
2. How does an API gateway typically differ from a BFF?
A gateway is general-purpose across clients, while a BFF customizes the contract for one specific client.
3. What is a key risk of the API gateway pattern if not designed carefully?
Because all traffic flows through it, the gateway must be built for high availability and horizontal scaling.
Flash Cards
What is an API gateway? — A single entry point routing requests to backend services while centralizing cross-cutting concerns.
Gateway vs BFF? — Gateway is general-purpose across clients; BFF is tailored to one specific client type.
Cross-cutting concerns handled at the gateway? — Auth, rate limiting, logging, TLS termination.
Main gateway risk? — Becoming a single point of failure or bottleneck without HA design.