5 exercises — choose the best-structured answer to common API gateway architecture interview questions. Focus on rate limiting, circuit breakers, versioning, mTLS, and gateway extensibility.
Structure for API gateway interview answers
Name the algorithm or pattern mechanically: define how it works, not just what it does
Cover state machines: circuit breakers and rate limiters have explicit states and transition conditions
Address distributed concerns: shared state, consistency, and failure modes across gateway instances
Cite specific tooling: Kong, Envoy, Nginx — name the config options and plugin interfaces
0 / 5 completed
1 / 5
The interviewer asks: "Compare token bucket, leaky bucket, and sliding window counter rate limiting algorithms — when would you implement each at an API gateway?" Which answer best covers rate limiting algorithm trade-offs?
Option B is strongest: it defines all three primary algorithms mechanically (token refill, queue drain, weighted sliding average), explains when bursting is allowed (token bucket) vs forbidden (leaky bucket), identifies the fixed-window boundary attack that sliding window solves, describes the sliding window log variant for maximum accuracy, and covers distributed consistency requirements (Redis atomic Lua scripts) and the under-counting risk of local-only counters. Options A and C each state one correct trade-off but don't explain the algorithms mechanically, the boundary attack, or distributed state consistency.
2 / 5
The interviewer asks: "How does a circuit breaker pattern work at the API gateway layer — explain the state machine and what metrics determine state transitions?" Which answer best covers circuit breaker internals?
Option B covers the complete state machine with precise transition conditions (failure rate + minimum volume threshold + error type classification — 4xx excluded), latency-based failure counting, Kong and Envoy implementation specifics (outlier_detection config, ejection multiplier), three fallback strategies, and the cascade failure prevention rationale (retry storms, timeout budget). Options A and C describe the three states correctly but don't specify the metrics for state transitions, why 4xx is excluded, implementation in specific gateways, or fallback strategies.
3 / 5
The interviewer asks: "Compare URL path versioning, header-based versioning, and content negotiation for API versioning — what are the trade-offs and which would you recommend for a large platform?" Which answer best covers API versioning trade-offs?
Option B covers all five layers: URL versioning pros/cons with concrete examples (Stripe, Twilio, GitHub), header versioning with the CDN caching problem (Vary header, cache miss rate), content negotiation with the Accept media type format and its practical downsides, a concrete recommendation for external vs internal APIs with the Stripe date-versioning pattern, and the Sunset policy with RFC 8594 and the gateway injection pattern. Options A and C each identify the right trade-offs but don't cover CDN caching mechanics, the Vary header problem, the Sunset RFC, or gateway-level deprecation headers.
4 / 5
The interviewer asks: "How do you implement mTLS at the API gateway to enforce zero trust for service-to-service calls — what does the gateway verify and what are common implementation pitfalls?" Which answer best covers gateway mTLS implementation?
Option B covers all five dimensions: the mechanical difference mTLS adds over TLS (bidirectional verification), both upstream and downstream gateway configurations (terminate + re-originate vs passthrough), the four certificate validation checks (CA trust, expiry, revocation via OCSP, SPIFFE SAN), automatic rotation via cert-manager/SPIRE, five specific pitfalls (internal-IP trust anti-pattern, pinning without rotation, revocation omission, passthrough L7 blind spot, chain validation latency), and the authentication vs authorisation separation. Options A, C, D each describe the basic concept but don't cover upstream mTLS configuration, revocation checking, the passthrough pitfall, or the auth vs authz separation.
5 / 5
The interviewer asks: "Compare request transformation approaches in Kong (Lua plugins) and Envoy (HTTP filters, WASM) — what can each do, and what are the performance trade-offs?" Which answer best covers gateway extensibility?
Option B provides the complete picture: Kong lifecycle hooks by name (access, header_filter, body_filter, log), LuaJIT performance numbers (0.1-0.3ms), plugin architecture (base_plugin.lua interface), Envoy built-in filter names (ext_authz, grpc_json_transcoder, lua, header_to_metadata), proxy-wasm ABI hook names with supported languages (Rust, Go, C++), performance numbers for all four tiers (C++ 0.01ms, Lua 0.1-0.5ms, WASM 0.2-1ms, ext_authz 1-5ms), and a concrete decision framework. Options A, C, D each name the right technologies but provide no performance numbers, lifecycle hook names, or decision criteria.