The API gateway questions a systems-design round actually asks

On 6 September 2026 I opened Kong’s own gateway documentation to check exactly what a real gateway claims to do, because a lot of API gateway interview questions get answered from a diagram someone half-remembers rather than a product someone has actually configured. Kong describes itself plainly: a reverse proxy that lets you “route requests to your APIs,” extended through plugins for things like rate limiting “by IP, API key, Consumer, and more.” That’s the whole job, stated by the vendor, with none of the buzzword padding most explainers add on top.

API gateway interview questions show up almost exclusively inside systems-design rounds, not as a standalone topic, which is exactly why candidates fumble them. Nobody drills gateway trivia the way they drill two-pointer arrays. This post groups the real questions by what the interviewer is checking, and it stays on the infrastructure layer, not the API design layer. LastRoundAI already covers request and response contract design in API developer interview questions; this one is about what sits in front of your APIs, not what’s inside them.

What a gateway actually does, beyond “it routes requests”

Q: List the concrete jobs an API gateway does, not the marketing description.
Model answer: routing requests to the right backend service, terminating and validating authentication so individual services don’t each reimplement it, enforcing rate limits per client, shaping requests and responses (header rewriting, aggregating multiple backend calls into one client-facing response), and centralizing observability like access logs and latency metrics. Amazon’s own documentation for API Gateway frames the aggregate of this as being the “front door” for applications, handling “traffic management, authorization and access control, monitoring, and API version management” so backend services don’t each own that plumbing separately.

Follow-up: “Which of those would you push down into the backend services instead, on a team of 6 engineers?” Fine-grained authorization logic, usually. Coarse authentication (is this token valid at all) belongs at the gateway; deciding whether this specific user can touch this specific resource often needs domain context the gateway doesn’t have, so it’s a genuinely debatable line, not a fixed rule.

Q: What’s request shaping, concretely?
Model answer: transforming a request or response as it passes through, without touching the backend. Stripping an internal header before it reaches the client, rewriting a path (/v2/users maps to an old service still expecting /users), or fanning one client request out to three backend calls and merging the results into a single JSON payload the client never has to assemble itself.

API gateway interview questions: gateway versus load balancer versus mesh versus BFF

This is the single most common trap. Interviewers ask it because a wrong answer here reveals whether you actually understand the layers, or just know the names.

Q: How is an API gateway different from a load balancer?
Model answer: a load balancer distributes traffic across identical instances of one service, mostly blind to what’s inside the request beyond maybe a health check and a routing key. A gateway operates one layer up, understanding API-level concepts (routes, methods, API keys, rate limit buckets) and often routes to entirely different services based on the path, not just spreading load across copies of the same one. In practice a gateway usually sits in front of, or alongside, one or more load balancers rather than replacing them.
Follow-up: “Could you build a gateway out of just a load balancer with clever rules?” Partially, for pure routing. You’d still be missing per-client rate limiting, auth termination, and response shaping unless you bolt those on separately, at which point you’ve built a worse gateway by hand.

Service mesh and Backend-for-Frontend: the other two boundaries

Q: When would you reach for a service mesh instead of, or alongside, a gateway?
Model answer: a gateway manages north-south traffic, meaning requests coming into your system from outside. A service mesh manages east-west traffic, meaning service-to-service calls inside your system, handling retries, mutual TLS, and circuit breaking between your own microservices. A large microservices shop often runs both: a gateway at the edge, a mesh internally. I’d be skeptical of introducing a mesh before you have real east-west traffic problems, since the operational overhead of running one (sidecar proxies on every pod, a control plane to maintain) is not small, and a lot of teams adopt one before they’ve hit a problem it solves.

Q: What’s a Backend for Frontend, and how does it relate to a gateway?
Model answer: a BFF is a thin, purpose-built backend layer for one specific client (mobile app, web app), shaped around exactly what that client needs. A gateway is generic infrastructure serving all clients uniformly. Some teams put a BFF behind a shared gateway. Others let the BFF absorb some gateway-like responsibilities (auth, aggregation) for its one client and skip a shared gateway entirely. There’s no universally correct answer here, and an interviewer asking this usually wants to hear you reason about trade-offs, not recite a definition.

Rate limiting and auth: the two things every gateway config actually does

Q: How would you rate limit by API key versus by IP, and when would you pick one over the other?
Model answer: rate limiting by API key ties the limit to an identity you control (issued to a specific customer or service), which is precise but requires every caller to actually authenticate. Rate limiting by IP is a cruder fallback, useful against anonymous or pre-auth traffic, but breaks down behind a shared corporate NAT where hundreds of real users share one IP, or fails to stop an attacker who rotates IPs. Kong’s own plugin documentation lists both as first-class options, “by IP, API key, Consumer, and more,” which tells you real gateway products treat this as a menu, not a single fixed strategy.

Follow-up: “A client complains they’re getting rate limited even though they’re well under their documented quota. Where do you look first?” Whether the limit is being applied per-node instead of globally across the gateway cluster; a lot of naive in-memory rate limiters reset per instance, so a client bouncing across 4 nodes effectively gets 4x the limit spread unevenly, and can hit a wall on one node while technically under quota overall.

Q: Where should authentication actually happen, at the gateway or in each service?
Model answer: token validation (is this JWT signed correctly, is it expired) belongs at the gateway, so every service doesn’t duplicate that logic and every service doesn’t need to trust a raw incoming token. Amazon API Gateway supports this directly through Lambda authorizer functions and Cognito user pools sitting in front of the actual backend integration. What the gateway typically can’t and shouldn’t decide is fine-grained authorization tied to business data, which usually needs the service’s own database state.

Failure modes and timeouts

This is where a lot of otherwise-solid candidates go quiet, because it’s the part that only shows up once something has actually broken in production.

Q: A backend service starts responding slowly. What happens at the gateway, and what should happen?
Model answer: without protection, slow responses pile up connections at the gateway, which can exhaust its own connection pool and start failing requests to healthy services too, a classic cascading failure. What should happen: a timeout on the upstream call, paired with a circuit breaker that stops sending traffic to a service after enough consecutive failures, giving it room to recover instead of getting hammered by retries while it’s already struggling.
Follow-up: “What’s wrong with retrying every failed request 3 times automatically?” It triples load on a service that’s already failing, which is close to the worst possible response, and it can turn a minor blip into a full outage. Retries need backoff and a cap, and probably shouldn’t apply at all to a service that’s already tripped its circuit breaker.

Q: The gateway itself goes down. What’s your blast radius?
Everything behind it, for every client, all at once, which is exactly why gateways are almost always deployed with redundancy (multiple instances behind their own load balancer) rather than as a single box. I don’t think there’s a fully satisfying answer to eliminating this single point of failure short of running a genuinely redundant fleet with health checks, because the gateway’s whole value is being one consistent front door, and a front door that’s also distributed and stateless everywhere gets architecturally complicated fast.

How this shows up in a system design round

Interviewers rarely say “tell me about API gateways” directly. It surfaces as: “design a system that serves both a mobile app and 3 partner integrations with different rate limits,” and the gateway is the correct answer buried inside a bigger prompt. The candidates who do well mention the gateway unprompted, place it correctly (after the load balancer, before the service layer, in most diagrams), and can explain what it would and wouldn’t handle without being asked follow-up after follow-up to drag it out of them.
A smaller number of candidates over-rely on it, routing every cross-cutting concern (business logic, data transformation, even database queries) through the gateway layer because they’ve heard it’s the “front door.” That’s a tell in the other direction, since the interviewer is also checking that you know where the gateway’s job ends.

What to check before you walk in

Open Kong’s own docs or AWS API Gateway’s developer guide for twenty minutes, not a third-party summary of them, because the exact feature list changes and secondhand explainers go stale fast (this post’s own numbers are dated 6 September 2026 for that reason). If you’re prepping the broader systems-design loop rather than just this one component, our system design interview guide covers where a gateway question typically sits inside a full 45-minute round.

One honest note on how this topic got prioritized: our own Search Console data showed the search “api gateway interview questions” already earning impressions on lastroundai.com at an average position around 65, with zero clicks over 45 days as of 6 September 2026. People are searching for this and finding nothing worth clicking. That gap is the reason this post exists, not a guess about volume.

Practicing the actual verbal answer to “where does auth belong, gateway or service” out loud, on something like LastRound AI‘s mock interview mode, tends to expose gaps that reading a docs page alone doesn’t.