API Gateway Interview Questions India 2026: Design, Rate Limiting, BFF, and Kong

API gateway fundamentals:

1. What is an API gateway? An API gateway is the single entry point for all client requests to a backend system (monolithic API or microservices). Every request from a web app, mobile app, or third-party partner passes through the gateway before reaching the backend services. Core responsibilities: routing (route /users requests to the users service, /orders to the orders service), authentication (verify JWT tokens; reject unauthenticated requests at the edge), rate limiting (reject requests that exceed per-user or per-IP limits), SSL termination (the gateway handles HTTPS; backend services receive plain HTTP), request/response transformation, caching (cache GET responses to reduce backend load), logging and monitoring.

2. API gateway vs load balancer: Load balancer (L4/L7): distributes traffic across multiple instances of a service; minimal processing; no business logic. API gateway (L7 only): extensive processing per request; authentication, rate limiting, caching, transformation, protocol translation. In practice: both exist together — a load balancer distributes traffic to multiple API gateway instances; the gateway then routes to backend services.

3. API gateway vs reverse proxy: A reverse proxy (NGINX, HAProxy) forwards requests to backend servers with minimal modification. An API gateway is a reverse proxy with additional API-specific functionality (auth, rate limiting, transformation). Kong is built on NGINX and adds API gateway features via plugins.

4. What problems does an API gateway solve? Without an API gateway: each backend service must implement its own authentication, rate limiting, and CORS handling (duplicated code across services). Clients must know the addresses of each backend service. Adding a new cross-cutting concern requires modifying every service. With an API gateway: cross-cutting concerns are implemented once; backend services focus on business logic; clients interact with one stable address.

API gateway design patterns:

1. Backend for Frontend (BFF) pattern: Create a separate API gateway for each type of client: one BFF for the web app, one for mobile, one for third-party partners. Each BFF is tailored to its client's needs: the mobile BFF aggregates multiple API calls into one to reduce round trips (mobile networks are higher latency); the mobile BFF returns smaller payloads for mobile (fewer fields, compressed images); the partner BFF enforces stricter rate limits and authentication. BFF decouples the evolution of client-specific APIs from the underlying backend services. Used at Swiggy, Flipkart, and Razorpay to serve different clients from optimised backends.

2. API aggregation: A single client request triggers multiple backend service calls; the gateway aggregates the responses into one response. Example: the product detail page fetches product info from the product service, reviews from the reviews service, pricing from the pricing service, stock from the inventory service, and returns all in one response. Without aggregation: the client makes 4 serial or parallel API calls. With aggregation at the gateway: one request, one response, simpler client code.

3. API versioning strategies: URL versioning: /api/v1/users vs /api/v2/users — simple, visible. Header versioning: Accept: application/vnd.api.v2+json — cleaner URLs; less cacheable. At the gateway, route to different backend service versions based on the URL or header. v1 requests go to the legacy service; v2 requests go to the new service. Allows gradual migration without a cutover.

4. Service mesh vs API gateway: Service mesh (Istio, Linkerd): handles service-to-service (east-west) communication within the cluster; mTLS, traffic management, observability between microservices. API gateway: handles client-to-service (north-south) traffic; external-facing API management. They are complementary: the API gateway is the external front door; the service mesh governs internal communication. Large Indian companies use both.

Rate limiting:

1. Why rate limiting? Protects backend services from overload. Prevents abuse (a bad actor making thousands of requests per second). Enforces fair use across customers. Prevents brute-force attacks on authentication endpoints.

2. Rate limiting algorithms: Token bucket: each user has a bucket of N tokens. Each request consumes one token. Tokens are added at a fixed rate (e.g., 100 tokens per second). If the bucket is empty, the request is rejected (HTTP 429). Allows bursts (a user who has not made requests recently has a full bucket). Most commonly used in practice.

Leaky bucket: a fixed-capacity queue accepts requests. Requests are processed at a constant rate. If the queue is full, new requests are rejected. Smooths out bursts (unlike token bucket, requests are processed at a steady rate).

Fixed window counter: count requests in the current time window. If the count exceeds the limit, reject. Problem: a burst at the boundary can process 2x the limit.

Sliding window: tracks requests in a rolling window (the last 60 seconds, not the current calendar minute). More accurate than fixed window; eliminates the boundary burst problem.

3. Distributed rate limiting: In a multi-instance API gateway, each instance must share rate limit state across the fleet. Use Redis (or Upstash Redis for serverless) as the shared counter store. Lua scripting in Redis: rate limiting logic runs as an atomic Lua script, preventing race conditions between instances.

4. Rate limit response headers: - X-RateLimit-Limit: 100 (requests per window) - X-RateLimit-Remaining: 47 (requests remaining) - X-RateLimit-Reset: 1720000000 (Unix timestamp when the window resets) - Retry-After: 30 (seconds until the client can retry, on 429)

API gateway implementations:

1. Authentication at the API gateway: JWT validation: the gateway extracts the JWT from the Authorization: Bearer header, verifies the signature (using the public key from the auth service or a JWKS endpoint), and checks expiry. The gateway adds the verified user ID as a request header (X-User-ID) to the forwarded request; backend services trust these headers without re-validating the JWT. API key authentication: the client sends an API key in a header (X-API-Key). The gateway validates the key against Redis and maps it to a customer ID. Mutual TLS (mTLS): both client and server present certificates; used for machine-to-machine communication.

2. Kong API Gateway: Kong is the most popular open-source API gateway; widely used at Indian fintech and e-commerce companies. Built on NGINX. Plugin architecture: authentication (JWT, OAuth 2.0, API key, LDAP), rate limiting, caching, logging, request transformation. Deployed on Kubernetes (Kong Ingress Controller). The Kong Admin API configures routes, services, and plugins programmatically. Kong Konnect: the managed cloud version. Many Indian product companies start with self-hosted Kong and move to Kong Konnect for managed operations.

3. AWS API Gateway: Managed service; no infrastructure to provision. Two types: REST API (full HTTP support; usage plans; API key management; request/response mapping; caching), HTTP API (simpler, cheaper, lower latency; OIDC/OAuth 2.0 auth out of the box). Integration targets: Lambda (serverless backends), HTTP (forward to any URL), AWS services. Used at Indian companies running on AWS (Razorpay, Paytm, Groww).

4. API gateway observability: Every request is logged by the gateway (request ID, timestamp, method, path, status code, latency, user ID, upstream service). Metrics: requests per second by route, error rate by route, p99 latency by route, rate limit hit rate. Distributed tracing: the gateway adds a trace ID to every request; downstream services include this ID in their traces. The API gateway is a natural observability choke point: dashboards per route tell you which endpoints are slow, failing, or being abused.