25 Advanced API Gateway Interview Questions for Experienced Developers

An API Gateway acts as a single, unified entry point for all client requests to a backend system composed of multiple microservices. Its primary role is to abstract the complexity of the microservices architecture from the client. It handles cross-cutting concerns such as request routing, authentication, rate limiting, and logging, allowing the individual microservices to focus solely on their core business logic. This creates a clear boundary and simplifies both client-side and server-side development.

• A **Load Balancer** typically operates at Layer 4 (TCP/UDP) and distributes traffic across a pool of identical backend servers. It is unaware of the application logic.
• A **Reverse Proxy** operates at Layer 7 (HTTP) and can make routing decisions based on URLs, but it’s generally a simple pass-through.
• An **API Gateway** is a specialized, more intelligent reverse proxy. It understands the business context of APIs and provides a rich set of features beyond simple routing, including authentication/authorization, request/response transformation, rate limiting, and API composition (the facade pattern).

They solve different problems related to network traffic, often complementing each other.

• An **API Gateway** manages **north-south traffic**: requests coming from external clients *into* the cluster. It is the single entry point and handles concerns like authentication and rate limiting for external consumers.
• A **Service Mesh** (like Istio or Linkerd) manages **east-west traffic**: communication *between* microservices already inside the cluster. It uses sidecar proxies to provide features like mutual TLS (mTLS), advanced traffic splitting, and deep observability for internal service-to-service calls.

High availability for an API Gateway involves eliminating single points of failure. This is typically achieved by:

1. Redundant Instances: Deploying multiple instances of the gateway across different nodes or virtual machines.
2. Load Balancing: Placing a Layer 4 load balancer in front of the gateway instances to distribute incoming traffic and handle instance failures.
3. Multi-Zone/Region Deployment: For maximum resilience, deploy gateway instances across multiple Availability Zones or even different geographic regions. A global load balancer can then route traffic to the nearest healthy gateway deployment.
4. Stateless Operation: Ensuring the gateway itself is stateless. Any state required for rate limiting or session management should be stored in an external, highly available data store like Redis or DynamoDB.

The API Facade pattern is where the API Gateway provides a simplified, unified API to clients while hiding the more complex and granular microservices backend. The gateway can compose calls to multiple downstream services and aggregate their results into a single response. This is a core function of an API Gateway, reducing the number of round trips a client needs to make and tailoring responses to specific client needs (like a mobile vs. web client).

An API Gateway is a critical security enforcement point. Common mechanisms include:

1. Authentication: The gateway can validate credentials before forwarding a request. This includes validating API keys, verifying JWT signatures, or introspecting OAuth 2.0 access tokens with an authorization server.
2. Authorization: After authenticating, the gateway can perform authorization checks. For example, it can inspect the scopes within a JWT and ensure the client has the required permissions for the requested operation.
3. Rate Limiting & Throttling: It can enforce policies to protect backend services from denial-of-service attacks or overuse by limiting the number of requests a client can make in a given period.

The gateway would be configured to perform the following steps for each incoming request:

1. Extract the JWT from the `Authorization: Bearer` header.
2. Check the signature of the token using the appropriate public key. The gateway can fetch these keys from a JWKS (JSON Web Key Set) endpoint and cache them.
3. Validate the standard claims of the token:
   • `exp`: Ensure the token has not expired.
   • `iss`: Ensure the token was issued by a trusted authorization server.
   • `aud`: Ensure the token was intended for this API (the audience).
4. If all checks pass, the request is allowed to proceed to the backend. The gateway might also pass the validated claims (like the user ID) to upstream services in a secure header.

Mutual TLS** is a process where both the client and the server cryptographically authenticate each other by presenting and validating certificates. This ensures that both parties are who they claim to be.

In an API Gateway context, mTLS can be used to secure the connection to backend services. The gateway would be configured with a client certificate, and the backend service would be configured to only accept connections from clients presenting that specific certificate. This prevents unauthorized services from directly calling your backend APIs, providing a strong layer of security for east-west traffic within your network.

A WAF is typically placed in front of an API Gateway. Its role is to inspect incoming HTTP traffic and protect against common web application vulnerabilities and attacks, such as SQL Injection, Cross-Site Scripting (XSS), and path traversal. While the API Gateway handles authentication and business logic routing, the WAF provides a crucial first line of defense against a broad range of common attack patterns.

While the ultimate responsibility for BOLA protection lies in the backend service, an advanced API Gateway can help. It can be configured with policies that extract a user identifier from the validated JWT (`sub` claim) and a resource identifier from the request path (e.g., `/users/{userId}`). The gateway can then enforce a policy that requires these two values to be identical. If a user with ID `123` tries to access `/users/456`, the gateway can block the request before it ever reaches the backend service, providing a centralized layer of defense.

The **Circuit Breaker** pattern prevents an application from repeatedly trying to call a service that is known to be failing. It works like an electrical circuit breaker:

1. Closed: Requests are passed through to the backend service. If the number of failures exceeds a threshold, the breaker “trips” and moves to the Open state.
2. Open: All subsequent requests are immediately rejected by the gateway with an error, without calling the failing service. This gives the backend time to recover.
3. Half-Open: After a timeout, the gateway allows a single trial request to pass through. If it succeeds, the breaker moves back to Closed. If it fails, it remains Open.

Implementing this at the gateway level protects clients from downstream failures and prevents a failing service from being completely overwhelmed.

• Token Bucket: A bucket is filled with tokens at a fixed rate. Each request consumes a token. If the bucket is empty, the request is rejected. This allows for bursts of traffic up to the bucket size.
• Leaky Bucket: Requests are placed in a queue (the bucket). They are processed at a fixed rate. If the queue is full, new requests are rejected. This smooths out traffic into a steady stream.
• Fixed Window Counter: Counts the number of requests in a fixed time window (e.g., 100 requests per minute). Simple, but can allow double the rate at the boundary of a window.
• Sliding Window Log: Keeps a log of timestamps for all requests. More accurate than the fixed window but uses more memory.

An API Gateway is the ideal place to control traffic for a canary release. You can configure the gateway with weighted routing rules. For example, you can initially configure it to send 99% of traffic to the stable version of a service and 1% to the new “canary” version. The gateway can then monitor the canary for error rates and latency. If the canary performs well, you can gradually adjust the weights in the gateway’s configuration to send more traffic to the new version until it handles 100% of the load. This allows for a controlled, low-risk rollout.

This is the process of modifying a request before it hits a backend service, or modifying a response before it’s returned to the client. A practical example is protocol translation. A client might send a modern JSON/REST request to the gateway. The gateway can then transform this request into an older XML/SOAP format that a legacy backend service understands. It can then transform the SOAP response back into JSON for the client. This allows you to modernize your public-facing API without immediately rewriting legacy services.

An API Gateway can be configured to cache the responses of backend requests. When a request comes in, the gateway constructs a cache key, typically from the URL path and key query parameters. It checks its cache for a response corresponding to that key. If a valid, non-expired response exists (a “cache hit”), it returns the cached response immediately without calling the backend. If not (a “cache miss”), it forwards the request to the backend, stores the response in the cache with a specific Time-To-Live (TTL), and then returns it to the client.

An API Gateway can handle different versioning strategies:

• Path Versioning (e.g., `/api/v1/users`): This is the most common. The gateway can simply route requests based on the version in the URL path to different backend services or different versions of the same service.
• Header Versioning (e.g., `Api-Version: 1`): The gateway can inspect the request header and use its value to route to the appropriate backend.
• Query Parameter Versioning (e.g., `?version=1`): Similar to header versioning, the gateway routes based on a query parameter.

The gateway provides a single entry point while allowing you to maintain multiple versions of a service in the backend simultaneously.

Most modern API Gateways have first-class support for OpenAPI. You can import an OpenAPI specification to automatically configure the gateway. This can create all the necessary routes, configure request validation based on the defined schemas, set up authentication requirements from the security schemes, and even create mock backends for testing. This “contract-first” approach ensures that the gateway’s configuration is always in sync with the API’s documented contract.

• A **Public API** is exposed to the internet for external consumers (e.g., third-party developers, mobile apps).
• A **Private API** is only accessible from within an organization’s private network (e.g., a VPC). It’s used for internal service-to-service communication.

An API Gateway can manage both, often by deploying different gateway instances. A public-facing gateway would be deployed in a public subnet with a public IP, while an internal gateway would be deployed in a private subnet with only an internal IP address, ensuring it cannot be reached from the internet.

Backend microservices may return errors in many different formats. The API Gateway can be used to intercept these backend responses and transform them into a standardized error format before returning them to the client. For example, it can catch a `503 Service Unavailable` from a backend and transform it into a standard JSON error response like `{“error”: {“code”: “SERVICE_UNAVAILABLE”, “message”: “The requested service is temporarily unavailable.”}}`. This provides a consistent and predictable error handling experience for all API consumers.

The BFF pattern is an architectural pattern where you create a dedicated backend service (the BFF) for each specific frontend application (e.g., one for your web app, one for your mobile app). This BFF is a specialized API Gateway that acts as a facade for downstream microservices.

Its purpose is to optimize for a specific client experience. The mobile BFF can aggregate data and provide a lean response tailored for a mobile device, while the web BFF can provide a more detailed response for a desktop browser. This avoids creating a single, bloated, one-size-fits-all API.

In a serverless architecture, an API Gateway is an essential component. It provides the HTTP front end for serverless functions (like AWS Lambda or Azure Functions). It receives an HTTP request, invokes the appropriate backend function, and then transforms the function’s response back into an HTTP response. It handles all the concerns of a web server, allowing the functions to be small, stateless, and event-driven.

Traditional API Gateways are built for REST and can struggle with GraphQL. Challenges include:

• Routing: All GraphQL requests go to a single endpoint (e.g., `/graphql`), so path-based routing doesn’t work. The gateway needs to be able to inspect the GraphQL query body to route it correctly in a federated setup.
• Caching: The flexible nature of GraphQL queries makes caching difficult. You can’t easily cache based on the URL.
• Rate Limiting: A simple request count is ineffective, as a single GraphQL query can be vastly more expensive than another. You need a more sophisticated cost-based analysis for rate limiting.

Modern gateways like Apollo Router or specialized configurations are designed to handle these challenges.

The API Gateway acts as the facade that directs traffic during the migration. Initially, all requests to the gateway are routed to the legacy monolith. When you build the first new microservice to replace a piece of functionality, you update the gateway’s routing rules. For example, you would change the route for `/api/users` to point to the new user microservice, while all other traffic continues to flow to the monolith. You repeat this process, “strangling” the monolith one endpoint at a time until it can be fully decommissioned.

Popular open-source API Gateways include:

• Kong: A highly performant, scalable, and extensible gateway built on top of Nginx and a plugin architecture.
• Tyk: A powerful gateway written in Go, which can be run open-source or as a managed cloud service.
• Apache APISIX: A high-performance, cloud-native gateway based on Nginx and etcd.
• Spring Cloud Gateway: A gateway built on top of the Spring ecosystem, designed for Java applications and integrating well with Spring Boot.

The API Gateway plays a crucial role in initiating and propagating trace contexts. The process is:

1. If an incoming request already has a trace context header (like `traceparent`), the gateway will forward it to the upstream service.
2. If no trace context exists, the gateway will **generate** a new trace ID and initial span ID.
3. It then injects this trace context into the request headers before forwarding it to the backend service.

This ensures that the entire request lifecycle, from the entry point at the gateway through all subsequent microservice calls, can be correlated into a single distributed trace.