Backend interview prep

Start

API Gateway Interview Questions and Answers

Learn API Gateway concepts with production-ready interview questions covering request routing, authentication, authorization, throttling, rate limiting, caching, transformations, security, monitoring, deployment, AWS API Gateway, Azure API Management, and Google Cloud API Gateway.

Module Navigation

Previous: Google Cloud Functions QA | Parent: Serverless Learning Path | Next: EventBridge QA

Introduction

An API Gateway is a managed entry point that receives client API requests and routes them to backend services.

Instead of allowing clients to directly access microservices, serverless functions, or internal applications, the API Gateway acts as an intermediary between clients and backend systems.

It can provide capabilities such as:

  • Request routing
  • Authentication
  • Authorization
  • Rate limiting
  • Throttling
  • Request validation
  • Response transformation
  • Caching
  • Logging
  • Monitoring
  • API versioning
  • Traffic management
  • Web Application Firewall integration

API Gateways are commonly used in:

  • Serverless applications
  • Microservices architectures
  • Mobile backends
  • Partner integrations
  • Public APIs
  • Internal enterprise APIs
  • Multi-cloud platforms
  • Legacy modernization

What Is an API Gateway?

An API Gateway is a reverse proxy and API-management layer positioned between clients and backend services.

It receives API requests, applies configured policies, forwards valid requests to the correct backend, and returns responses to clients.

flowchart LR
    Client[Web or Mobile Client] --> Gateway[API Gateway]
    Gateway --> Function[Serverless Function]
    Gateway --> ServiceA[Microservice A]
    Gateway --> ServiceB[Microservice B]
    Gateway --> Legacy[Legacy Application]

The client interacts with one API endpoint while the gateway hides the internal architecture.

Why Do We Need an API Gateway?

Without an API Gateway, clients may need to:

  • Know every backend service address
  • Handle multiple authentication models
  • Implement retries independently
  • Understand internal service changes
  • Communicate directly with private systems
  • Manage API versions separately
  • Apply client-side rate control

An API Gateway centralizes these concerns.

flowchart TB
    Client[Client Application] --> Gateway[Central API Gateway]

    Gateway --> Auth[Authentication]
    Gateway --> Rate[Rate Limiting]
    Gateway --> Validation[Request Validation]
    Gateway --> Routing[Request Routing]
    Gateway --> Logging[Logging]

    Routing --> BackendA[Backend A]
    Routing --> BackendB[Backend B]
    Routing --> BackendC[Backend C]

API Gateway Request Flow

A typical request passes through the following stages:

  1. Client sends an HTTP request.
  2. API Gateway receives the request.
  3. TLS connection is validated.
  4. Authentication information is verified.
  5. Authorization rules are evaluated.
  6. Rate limits and quotas are checked.
  7. Request schema is validated.
  8. Headers or payloads may be transformed.
  9. The request is routed to a backend.
  10. The backend processes the request.
  11. The response may be transformed or cached.
  12. Logs, metrics, and traces are recorded.
  13. The response is returned to the client.

API Gateway Sequence Flow

sequenceDiagram
    participant Client
    participant Gateway as API Gateway
    participant Identity as Identity Provider
    participant Backend as Backend Service
    participant Monitor as Monitoring
    Client->>Gateway: Send API request
    Gateway->>Identity: Validate token
    Identity-->>Gateway: Identity confirmed
    Gateway->>Gateway: Check authorization and rate limit
    Gateway->>Backend: Forward request
    Backend-->>Gateway: Return response
    Gateway->>Monitor: Record logs and metrics
    Gateway-->>Client: Return API response

Core API Gateway Responsibilities

Capability Description
Routing Sends requests to the correct backend
Authentication Verifies caller identity
Authorization Determines whether access is allowed
Rate limiting Controls request volume over time
Throttling Restricts excessive traffic
Validation Checks headers, parameters, and payloads
Transformation Modifies requests and responses
Caching Stores responses to reduce backend calls
Versioning Supports multiple API versions
Monitoring Records traffic, errors, and latency
Security Integrates with WAF, TLS, IAM, and identity providers
Documentation Publishes API contracts and developer information

API Gateway as a Reverse Proxy

A reverse proxy receives requests on behalf of backend servers.

flowchart LR
    Client[Client] --> Gateway[API Gateway]
    Gateway --> InternalService[Private Backend Service]

The client sees the gateway endpoint rather than the private backend address.

Benefits include:

  • Backend isolation
  • Centralized security
  • Simplified client configuration
  • Traffic control
  • Internal architecture flexibility

API Gateway vs Load Balancer

API Gateway Load Balancer
API-aware management layer Distributes network or application traffic
Supports authentication policies Primarily balances traffic
Provides quotas and rate limits Provides health checks and routing
Supports request transformation Usually limited transformation
Supports API keys and usage plans Does not normally manage API consumers
Provides API analytics Provides infrastructure traffic metrics
Suitable for public and partner APIs Suitable for scaling backend instances

An architecture may use both.

flowchart LR
    Client --> Gateway[API Gateway]
    Gateway --> LoadBalancer[Load Balancer]
    LoadBalancer --> Service1[Service Instance 1]
    LoadBalancer --> Service2[Service Instance 2]

API Gateway vs Service Mesh

API Gateway Service Mesh
Manages north-south traffic Manages east-west traffic
Handles external client requests Handles service-to-service communication
Performs API authentication Performs workload identity and mTLS
Applies client quotas Applies service communication policies
Usually centralized entry point Distributed sidecar or proxy model
Exposes public or partner APIs Protects internal microservices

Many enterprise systems use an API Gateway for external traffic and a service mesh for internal traffic.

API Gateway vs Ingress Controller

API Gateway Kubernetes Ingress Controller
Full API-management capabilities Routes traffic into Kubernetes
Supports API products and subscriptions Supports host and path routing
Provides developer portals Usually no developer portal
Supports quotas and API keys Limited consumer management
Can route to many platforms Primarily routes to Kubernetes services

Some modern ingress products provide API Gateway capabilities, but their primary responsibilities may differ.

Common API Gateway Patterns

Single Gateway Pattern

One gateway exposes all APIs.

flowchart LR
    Clients[Clients] --> Gateway[Central API Gateway]
    Gateway --> User[User Service]
    Gateway --> Order[Order Service]
    Gateway --> Payment[Payment Service]

This is simple but may create a large shared dependency.

Gateway per Domain

Each business domain has its own gateway.

flowchart LR
    Client --> CustomerGateway[Customer API Gateway]
    Client --> PaymentGateway[Payment API Gateway]

    CustomerGateway --> CustomerServices[Customer Services]
    PaymentGateway --> PaymentServices[Payment Services]

This improves ownership and isolation.

Backend for Frontend Pattern

Different client types receive separate gateways or backend layers.

flowchart LR
    Web[Web Client] --> WebGateway[Web BFF]
    Mobile[Mobile Client] --> MobileGateway[Mobile BFF]
    Partner[Partner Client] --> PartnerGateway[Partner API]

    WebGateway --> Services[Backend Services]
    MobileGateway --> Services
    PartnerGateway --> Services

Each client receives an API optimized for its requirements.

API Routing

API Gateway routes requests using information such as:

  • URL path
  • HTTP method
  • Hostname
  • Header
  • Query parameter
  • API version
  • Stage
  • Client identity

Example routes:

Method Path Backend
GET /customers/{id} Customer service
POST /orders Order function
POST /payments Payment service
GET /products Product service
DELETE /orders/{id} Order cancellation service

Path-Based Routing

flowchart LR
    Client --> Gateway[API Gateway]

    Gateway -->|/customers| Customer[Customer Service]
    Gateway -->|/orders| Order[Order Service]
    Gateway -->|/payments| Payment[Payment Service]

Path-based routing allows multiple services to be exposed through one domain.

Authentication

Authentication verifies who the caller is.

Common authentication methods include:

  • OAuth 2.0 access tokens
  • OpenID Connect tokens
  • JSON Web Tokens
  • API keys
  • IAM-based authentication
  • Mutual TLS
  • Basic authentication for limited legacy scenarios
  • Custom authorizers

API keys generally identify a client application but should not always be treated as strong user authentication.

Authorization

Authorization determines what an authenticated caller is allowed to do.

Common models include:

  • Role-Based Access Control
  • Attribute-Based Access Control
  • Scope-based authorization
  • Policy-based authorization
  • Resource-based authorization

Example:

flowchart LR
    Client --> Gateway[API Gateway]
    Gateway --> Token[Validate JWT]
    Token --> Role{User Role}

    Role -->|Admin| AdminAPI[Administrative API]
    Role -->|Customer| CustomerAPI[Customer API]
    Role -->|Unauthorized| Deny[Return 403]

Authentication vs Authorization

Authentication Authorization
Verifies identity Verifies permissions
Answers "Who are you?" Answers "What can you access?"
Uses tokens, credentials, or certificates Uses roles, policies, scopes, and attributes
Failure commonly returns HTTP 401 Failure commonly returns HTTP 403

JWT Validation

API Gateways commonly validate JSON Web Tokens.

A JWT normally contains:

  • Issuer
  • Subject
  • Audience
  • Expiration
  • Scopes
  • Roles
  • Claims
  • Digital signature
sequenceDiagram
    participant User
    participant IdP as Identity Provider
    participant Gateway as API Gateway
    participant Backend
    User->>IdP: Authenticate
    IdP-->>User: Return JWT
    User->>Gateway: Request with JWT
    Gateway->>Gateway: Validate issuer, audience, expiry, and signature
    Gateway->>Backend: Forward authorized request
    Backend-->>Gateway: Response
    Gateway-->>User: Response

The gateway should validate:

  • Token signature
  • Issuer
  • Audience
  • Expiration
  • Not-before time
  • Required scopes
  • Required claims

API Keys

An API key is a value used to identify an API consumer or application.

API keys can support:

  • Usage tracking
  • Consumer identification
  • Rate limiting
  • Quotas
  • Subscription management

However, an API key alone may not prove the identity of an individual user.

Sensitive APIs should generally combine API keys with stronger authentication when appropriate.

Mutual TLS

Mutual TLS authenticates both:

  • The server to the client
  • The client to the server
sequenceDiagram
    participant Client
    participant Gateway as API Gateway
    Client->>Gateway: Present client certificate
    Gateway->>Client: Present server certificate
    Gateway->>Gateway: Validate client certificate
    Gateway-->>Client: Establish secure connection

mTLS is commonly used for:

  • Partner APIs
  • Financial services
  • Business-to-business integrations
  • Highly regulated systems
  • Service-to-service communication

Rate Limiting

Rate limiting controls how many requests a client can send within a time period.

Examples:

  • 100 requests per minute
  • 1,000 requests per hour
  • 10 requests per second
flowchart LR
    Client --> Gateway[API Gateway]
    Gateway --> Counter{Within Limit?}
    Counter -->|Yes| Backend[Backend Service]
    Counter -->|No| Reject[HTTP 429 Too Many Requests]

Rate limiting protects:

  • Backend capacity
  • API availability
  • Infrastructure cost
  • External dependencies
  • Fair API usage

Throttling

Throttling temporarily rejects or delays requests when configured limits are exceeded.

Rate limiting and throttling are closely related.

A common response is:

HTTP/1.1 429 Too Many Requests
Retry-After: 30

Clients should implement:

  • Exponential backoff
  • Retry limits
  • Jitter
  • Respect for Retry-After

Rate Limiting Algorithms

Token Bucket

Tokens are added to a bucket at a fixed rate. Each request consumes one token.

flowchart LR
    Refill[Token Refill] --> Bucket[Token Bucket]
    Request[Incoming Request] --> Bucket
    Bucket -->|Token Available| Allow[Allow Request]
    Bucket -->|No Token| Reject[Reject Request]

Token bucket supports controlled bursts.

Leaky Bucket

Requests enter a queue and leave at a controlled rate.

Fixed Window

Requests are counted within fixed time windows.

Sliding Window

Requests are evaluated across a moving time interval.

Quotas

A quota controls the total amount of API usage over a longer period.

Examples:

  • 10,000 requests per day
  • 1 million requests per month
  • 100 GB of data transfer per month
Rate Limit Quota
Controls short-term traffic Controls long-term usage
Example: requests per second Example: requests per month
Protects immediate capacity Controls plan or subscription usage

Request Validation

API Gateway can validate:

  • Required headers
  • Query parameters
  • Path parameters
  • Content type
  • JSON schema
  • Payload size
  • HTTP method
  • Authentication token
flowchart TD
    Request[Incoming Request] --> Validate{Valid Request?}
    Validate -->|Yes| Backend[Invoke Backend]
    Validate -->|No| BadRequest[Return HTTP 400]

Early validation prevents invalid traffic from reaching backend services.

Request and Response Transformation

API Gateway can transform data between clients and backends.

Examples include:

  • Renaming headers
  • Adding correlation IDs
  • Converting XML to JSON
  • Removing sensitive headers
  • Changing payload structures
  • Mapping backend errors
  • Adding API-version information
flowchart LR
    ClientRequest[Client Request] --> Gateway[API Gateway]
    Gateway --> Transform[Request Transformation]
    Transform --> Backend[Backend Service]
    Backend --> ResponseTransform[Response Transformation]
    ResponseTransform --> ClientResponse[Client Response]

Transformations should remain manageable. Excessive business logic inside the gateway can make systems difficult to maintain.

API Caching

Caching stores API responses for repeated requests.

flowchart TD
    Request[GET Request] --> Cache{Cached Response?}
    Cache -->|Yes| Return[Return Cached Response]
    Cache -->|No| Backend[Call Backend]
    Backend --> Store[Store in Cache]
    Store --> Return

Caching can:

  • Reduce backend calls
  • Improve response time
  • Reduce cost
  • Increase availability

Caching is best for:

  • Read-heavy APIs
  • Slowly changing data
  • Public reference information
  • Product catalogs
  • Configuration data

Avoid caching sensitive or rapidly changing responses without appropriate controls.

Cache Key

A cache key may include:

  • URL path
  • Query parameters
  • Selected headers
  • Client identity
  • API version

Incorrect cache-key design can return one user's data to another user.

Sensitive user-specific data requires careful cache isolation or caching should be disabled.

Cache Invalidation

Cached data may be invalidated through:

  • Time-to-live expiration
  • Explicit invalidation
  • Deployment
  • Backend event
  • Administrative action

Cache invalidation strategy should be part of API design.

CORS

Cross-Origin Resource Sharing controls whether browser applications from one origin may access an API hosted on another origin.

CORS configuration may specify:

  • Allowed origins
  • Allowed methods
  • Allowed headers
  • Exposed headers
  • Whether credentials are allowed
  • Preflight cache duration
sequenceDiagram
    participant Browser
    participant Gateway as API Gateway
    Browser->>Gateway: OPTIONS preflight request
    Gateway-->>Browser: CORS policy response
    Browser->>Gateway: Actual API request
    Gateway-->>Browser: API response

Using * for allowed origins should be avoided for sensitive APIs.

API Versioning

API versioning allows an API to evolve without immediately breaking existing clients.

Common strategies include:

URL Versioning

/api/v1/orders
/api/v2/orders

Header Versioning

Accept-Version: 2

Query Parameter Versioning

/orders?version=2

URL versioning is simple and widely understood, while header-based versioning keeps URLs cleaner.

API Lifecycle

flowchart LR
    Design[Design] --> Develop[Develop]
    Develop --> Test[Test]
    Test --> Publish[Publish]
    Publish --> Monitor[Monitor]
    Monitor --> Version[Version]
    Version --> Deprecate[Deprecate]
    Deprecate --> Retire[Retire]

A mature API lifecycle includes:

  • Contract design
  • Documentation
  • Security review
  • Testing
  • Publishing
  • Monitoring
  • Versioning
  • Deprecation
  • Retirement

OpenAPI Specification

OpenAPI defines an API contract in a machine-readable format.

It can describe:

  • Paths
  • HTTP methods
  • Request parameters
  • Request bodies
  • Response schemas
  • Authentication requirements
  • Error responses
  • API metadata

API Gateways can use OpenAPI definitions to:

  • Configure routes
  • Validate requests
  • Generate documentation
  • Create SDKs
  • Apply security requirements

Serverless API Architecture

flowchart TB
    Client[Web or Mobile Client] --> CDN[CDN]
    CDN --> WAF[Web Application Firewall]
    WAF --> Gateway[API Gateway]

    Gateway --> Auth[Identity Provider]
    Gateway --> OrderFunction[Order Function]
    Gateway --> CustomerFunction[Customer Function]

    OrderFunction --> Orders[(Orders Database)]
    CustomerFunction --> Customers[(Customer Database)]

    OrderFunction --> Queue[Message Queue]
    Queue --> Worker[Background Function]

    Gateway --> Monitoring[Logs and Metrics]
    OrderFunction --> Monitoring
    CustomerFunction --> Monitoring

AWS API Gateway

Amazon API Gateway is AWS's managed API service.

It can expose:

  • Lambda functions
  • HTTP endpoints
  • AWS services
  • Private integrations
  • Load balancers
  • Containerized applications

Common API types include:

  • HTTP APIs
  • REST APIs
  • WebSocket APIs

AWS API Gateway Components

Component Description
API Top-level API definition
Resource URL path
Method HTTP operation
Integration Backend connection
Stage Deployment environment
Authorizer Authentication and authorization logic
Usage plan Quota and throttling configuration
API key Consumer identifier
Mapping template Request or response transformation
Deployment Published API configuration

AWS API Gateway and Lambda

flowchart LR
    Client --> APIGateway[Amazon API Gateway]
    APIGateway --> Authorizer[JWT or Lambda Authorizer]
    Authorizer --> Lambda[AWS Lambda]
    Lambda --> DynamoDB[(Amazon DynamoDB)]
    APIGateway --> CloudWatch[Amazon CloudWatch]

The gateway validates and routes requests before Lambda executes business logic.

AWS HTTP API vs REST API

HTTP API REST API
Lower cost More advanced API-management features
Lower latency Supports broader transformation capabilities
Simpler configuration Supports usage plans and API keys
JWT authorizers Supports multiple authorizer types
Best for common serverless APIs Best for complex enterprise API requirements

The API type should be selected based on required features rather than habit.

AWS API Gateway Authorizers

Common authorization options include:

  • IAM authorization
  • JWT authorizer
  • Amazon Cognito authorizer
  • Lambda authorizer

A Lambda authorizer executes custom authorization logic and returns an access policy.

sequenceDiagram
    participant Client
    participant Gateway as API Gateway
    participant Authorizer as Lambda Authorizer
    participant Backend as Lambda Backend
    Client->>Gateway: Request with token
    Gateway->>Authorizer: Validate token
    Authorizer-->>Gateway: Allow or deny policy
    Gateway->>Backend: Forward authorized request
    Backend-->>Gateway: Response
    Gateway-->>Client: Response

Azure API Management

Azure API Management provides API publishing, security, transformation, analytics, and developer-portal capabilities.

It commonly integrates with:

  • Azure Functions
  • App Service
  • AKS
  • Logic Apps
  • Internal APIs
  • External services

Azure API Management Architecture

flowchart LR
    Consumer[API Consumer] --> APIM[Azure API Management]
    APIM --> Entra[Microsoft Entra ID]
    APIM --> Function[Azure Function]
    APIM --> AKS[AKS Services]
    APIM --> Legacy[Legacy API]
    APIM --> Monitor[Azure Monitor]

Azure API Management Policies

Policies can be applied for:

  • Token validation
  • Rate limiting
  • Quotas
  • Header transformation
  • IP filtering
  • Caching
  • Retry
  • Backend routing
  • Response transformation
  • Mock responses

Policies should handle cross-cutting API concerns rather than core business logic.

Google Cloud API Gateway

Google Cloud API Gateway provides managed API access to backend services based on an OpenAPI definition.

It can expose backends such as:

  • Cloud Run functions
  • Cloud Run services
  • App Engine
  • Other HTTP services
flowchart LR
    Client --> Gateway[Google Cloud API Gateway]
    Gateway --> IAM[Authentication and IAM]
    Gateway --> Function[Cloud Run Function]
    Function --> Firestore[(Firestore)]
    Gateway --> Logging[Cloud Logging]

Cloud Provider Comparison

Capability AWS Azure Google Cloud
API service Amazon API Gateway Azure API Management Google Cloud API Gateway
Serverless backend AWS Lambda Azure Functions Cloud Run functions
Identity IAM, Cognito, JWT Microsoft Entra ID Cloud IAM and identity tokens
WAF AWS WAF Azure Web Application Firewall Cloud Armor
Monitoring CloudWatch Azure Monitor Cloud Monitoring
Logging CloudWatch Logs Application Insights Cloud Logging
API contracts OpenAPI OpenAPI OpenAPI
Developer portal Available with API services Strong APIM capability Product-dependent capabilities
Usage plans Supported Products and subscriptions Quotas and API controls
Private integration VPC Link and private APIs VNet and self-hosted options Private backends and network controls

API Gateway Security Architecture

flowchart TB
    Client[Client] --> DDoS[DDoS Protection]
    DDoS --> WAF[Web Application Firewall]
    WAF --> Gateway[API Gateway]

    Gateway --> TLS[TLS Termination]
    Gateway --> AuthN[Authentication]
    Gateway --> AuthZ[Authorization]
    Gateway --> RateLimit[Rate Limiting]
    Gateway --> Validation[Request Validation]

    Validation --> Backend[Backend Service]
    Backend --> Database[(Database)]

    Gateway --> Audit[Audit Logs]
    Gateway --> SIEM[SIEM Monitoring]

API Gateway Security Best Practices

  • Require HTTPS.
  • Disable weak TLS versions.
  • Validate JWT issuer, audience, signature, and expiration.
  • Apply least-privilege backend permissions.
  • Use WAF protection.
  • Configure rate limits.
  • Validate request schemas.
  • Restrict allowed HTTP methods.
  • Restrict CORS origins.
  • Avoid sensitive data in URLs.
  • Mask secrets in logs.
  • Use mTLS for high-security partner integrations.
  • Separate public and private APIs.
  • Rotate API keys.
  • Monitor authentication failures.
  • Use private integrations where possible.

Backend Authentication

The gateway should authenticate to backends securely.

Common approaches include:

  • IAM role
  • Managed identity
  • Service account
  • OAuth token
  • Signed request
  • Mutual TLS
  • Private network identity

Backend systems should not blindly trust requests solely because they originated from the gateway network.

Private APIs

Private APIs are accessible only through controlled networks or identities.

Common access options include:

  • VPC or VNet
  • Private endpoint
  • VPN
  • Direct Connect or ExpressRoute
  • Internal load balancer
  • Private DNS
  • Service identity
flowchart LR
    CorporateUser[Corporate User] --> VPN[VPN or Private Network]
    VPN --> PrivateGateway[Private API Gateway]
    PrivateGateway --> InternalService[Internal Service]

API Gateway High Availability

A production API Gateway should support:

  • Multi-zone availability
  • Health monitoring
  • Regional redundancy
  • Failover planning
  • Deployment rollback
  • Backend timeout controls
  • Circuit breakers
  • Disaster recovery

For globally distributed APIs, architects may use:

  • Global DNS
  • CDN
  • Global load balancing
  • Multiple gateway regions
  • Active-active routing
  • Active-passive failover

Multi-Region API Architecture

flowchart TB
    Client[Global Clients] --> DNS[Global DNS or Traffic Manager]

    DNS --> GatewayA[API Gateway Region A]
    DNS --> GatewayB[API Gateway Region B]

    GatewayA --> BackendA[Backend Region A]
    GatewayB --> BackendB[Backend Region B]

    BackendA --> DatabaseA[(Regional Database)]
    BackendB --> DatabaseB[(Regional Database)]

Data replication and failover behavior must be carefully designed.

Timeouts

API Gateway and backend timeouts must be aligned.

Potential timeout layers include:

  • Client timeout
  • CDN timeout
  • API Gateway timeout
  • Function timeout
  • HTTP-client timeout
  • Database timeout
  • External API timeout
flowchart LR
    Client --> Gateway[API Gateway]
    Gateway --> Function[Serverless Function]
    Function --> External[External Service]

For long-running operations, an asynchronous API is usually better.

Asynchronous API Pattern

sequenceDiagram
    participant Client
    participant Gateway as API Gateway
    participant Function as Request Function
    participant Queue
    participant Worker
    participant Status as Status Store
    Client->>Gateway: Submit request
    Gateway->>Function: Validate request
    Function->>Queue: Publish work item
    Function->>Status: Create pending status
    Function-->>Gateway: Return 202 with request ID
    Gateway-->>Client: HTTP 202 Accepted
    Queue->>Worker: Process work
    Worker->>Status: Update result
    Client->>Gateway: Check request status
    Gateway->>Status: Read status
    Status-->>Gateway: Return result
    Gateway-->>Client: Processing status

This pattern avoids keeping an API connection open for long-running work.

Error Handling

API Gateway should provide consistent error responses.

Example:

{
  "code": "ORDER_VALIDATION_FAILED",
  "message": "The order request is invalid.",
  "correlationId": "3c95fa1a-87ce-45fc-801d-411672ab9516",
  "timestamp": "2026-07-18T14:30:00Z"
}

Common HTTP status codes include:

Code Meaning
400 Invalid request
401 Authentication required or invalid
403 Authenticated but not authorized
404 Resource not found
409 Business conflict
429 Rate limit exceeded
500 Internal server error
502 Invalid backend response
503 Service unavailable
504 Backend timeout

Internal exception details should not be exposed to clients.

Circuit Breaker Pattern

A circuit breaker prevents repeated calls to an unhealthy backend.

flowchart TD
    Request[API Request] --> State{Circuit State}

    State -->|Closed| Backend[Call Backend]
    Backend --> Result{Successful?}
    Result -->|Yes| Success[Return Response]
    Result -->|No| FailureCount[Increase Failure Count]

    FailureCount --> Threshold{Threshold Reached?}
    Threshold -->|Yes| Open[Open Circuit]
    Threshold -->|No| Backend

    State -->|Open| Reject[Fail Fast]
    Open --> Wait[Wait Period]
    Wait --> HalfOpen[Half-Open]
    HalfOpen --> Backend

Circuit breaking may be implemented in the gateway, service mesh, or backend client depending on the architecture.

Observability

API Gateway observability should include:

  • Request count
  • Successful response count
  • Client errors
  • Server errors
  • Latency
  • Backend latency
  • Authentication failures
  • Authorization failures
  • Throttled requests
  • Cache hit rate
  • Payload size
  • Traffic by consumer
  • Traffic by endpoint

Important API Metrics

Metric Purpose
Request count Measures API traffic
2xx rate Measures successful requests
4xx rate Identifies client-side errors
5xx rate Identifies gateway or backend failures
P50 latency Typical response time
P95 latency High-percentile latency
P99 latency Tail latency
Backend latency Measures service-processing time
Throttle count Detects rate-limit rejections
Authentication failure count Detects invalid credentials
Cache hit ratio Measures cache efficiency
Availability Measures API uptime

Distributed Tracing

A gateway should generate or propagate trace context.

flowchart LR
    Client --> Gateway[API Gateway]
    Gateway --> Function[Order Function]
    Function --> Queue[Message Queue]
    Queue --> Worker[Payment Worker]
    Worker --> Database[(Database)]

    Gateway --> Trace[Distributed Trace]
    Function --> Trace
    Worker --> Trace

Useful identifiers include:

  • Trace ID
  • Span ID
  • Correlation ID
  • Request ID
  • Business transaction ID

These identifiers should be returned safely in error responses and logged across services.

Logging

API Gateway logs may include:

  • Timestamp
  • HTTP method
  • Route
  • Status code
  • Latency
  • Client identity
  • API key identifier
  • Source IP
  • User agent
  • Correlation ID
  • Backend status
  • Throttle result

Avoid logging:

  • Passwords
  • Access tokens
  • Full API keys
  • Payment-card data
  • Personal information
  • Private keys
  • Secret headers

API Gateway Deployment Stages

API Gateways commonly use environments such as:

  • Development
  • Testing
  • Staging
  • Production
flowchart LR
    Code[API Configuration] --> Dev[Development]
    Dev --> Test[Testing]
    Test --> Stage[Staging]
    Stage --> Prod[Production]

Each environment should have independent:

  • Backend endpoints
  • Credentials
  • Rate limits
  • Logs
  • Monitoring
  • API keys
  • Network policies

Canary Deployment

Canary deployment sends a small percentage of traffic to a new API version or backend.

flowchart LR
    Requests[Incoming Requests] --> Gateway[API Gateway]
    Gateway -->|90 Percent| Stable[Stable Backend]
    Gateway -->|10 Percent| Canary[New Backend]

The canary should be monitored for:

  • Error rate
  • Latency
  • Business failures
  • Resource usage
  • Authentication issues

Traffic can be increased gradually or rolled back.

Blue-Green Deployment

flowchart LR
    Client --> Gateway[API Gateway]
    Gateway --> Blue[Blue Environment]
    Gateway -. Switch .-> Green[Green Environment]

Blue-green deployment maintains two environments and switches traffic after validation.

Cost Considerations

API Gateway cost may depend on:

  • Number of API requests
  • Data transfer
  • Cache capacity
  • Gateway tier
  • Logging volume
  • Monitoring
  • WAF requests
  • Private networking
  • Developer-portal features
  • Multi-region deployment

The total architecture cost may also include:

  • Serverless functions
  • Databases
  • Message queues
  • Identity providers
  • Load balancers
  • NAT gateways
  • Observability platforms

Production Use Case: Banking API

Consider a banking application that exposes account and transaction APIs.

flowchart TB
    Mobile[Mobile Banking App] --> WAF[Web Application Firewall]
    WAF --> Gateway[API Gateway]

    Gateway --> Identity[Identity Provider]
    Gateway --> RateLimit[Rate Limiting]
    Gateway --> Validation[Schema Validation]

    Validation --> AccountFunction[Account Function]
    Validation --> TransferFunction[Transfer Function]

    AccountFunction --> Accounts[(Accounts Database)]
    TransferFunction --> Queue[Transfer Queue]
    Queue --> TransferWorker[Transfer Worker]

    TransferWorker --> Ledger[(Ledger Database)]
    TransferWorker --> EventBus[Event Bus]
    EventBus --> Notification[Notification Function]

    Gateway --> Logs[Audit and Access Logs]
    TransferFunction --> Traces[Distributed Tracing]

Processing Flow

  1. The mobile application authenticates the customer.
  2. The identity provider issues an access token.
  3. The application sends a request to the gateway.
  4. The WAF filters malicious traffic.
  5. The gateway validates the token.
  6. Authorization scopes are checked.
  7. Rate limits are enforced.
  8. The request schema is validated.
  9. Account queries are processed synchronously.
  10. Money transfers are submitted asynchronously.
  11. The gateway returns a transaction ID.
  12. Logs, metrics, audit events, and traces are recorded.

Interview Questions and Answers

1. What is an API Gateway?

Answer

An API Gateway is a managed entry point that receives client API requests and routes them to backend services.

It centralizes concerns such as:

  • Authentication
  • Authorization
  • Routing
  • Rate limiting
  • Request validation
  • Transformation
  • Caching
  • Logging
  • Monitoring

The gateway hides backend implementation details and provides clients with a consistent API endpoint.

2. Why is an API Gateway used in serverless architecture?

Answer

A serverless function normally needs a secure and manageable endpoint before it can serve external clients.

An API Gateway can:

  • Expose an HTTPS endpoint
  • Authenticate users
  • Authorize requests
  • Validate input
  • Apply throttling
  • Route to the correct function
  • Transform requests and responses
  • Record access logs
  • Monitor latency and errors

This keeps cross-cutting API concerns outside individual functions.

3. What is the difference between an API Gateway and a load balancer?

Answer

A load balancer distributes traffic across backend instances, while an API Gateway provides API-management capabilities.

An API Gateway commonly supports:

  • Authentication
  • API keys
  • Quotas
  • Rate limiting
  • Request validation
  • Transformation
  • API analytics
  • Versioning

A load balancer mainly provides:

  • Traffic distribution
  • Health checks
  • High availability
  • Host and path routing

Both may be used together.

4. How does API Gateway authentication work?

Answer

The client sends credentials such as:

  • OAuth token
  • JWT
  • API key
  • Client certificate
  • Signed request

The gateway validates the credential before forwarding the request.

For JWT validation, the gateway verifies:

  • Signature
  • Issuer
  • Audience
  • Expiration
  • Required scopes
  • Required claims

If authentication fails, the gateway normally returns HTTP 401.

5. What is the difference between rate limiting and throttling?

Answer

Rate limiting defines how many requests a client can send during a time period.

Throttling enforces the limit by delaying or rejecting excess requests.

For example:

  • Limit: 100 requests per minute
  • Excess requests: rejected with HTTP 429

Rate limiting protects backends, controls cost, and ensures fair usage.

6. How does API Gateway caching work?

Answer

The gateway stores responses for selected requests.

When another request with the same cache key arrives:

  1. The gateway checks the cache.
  2. A valid cached response is returned immediately.
  3. The backend is not called.
  4. When the entry expires, the next request refreshes it.

Caching improves latency and reduces backend load, but sensitive or rapidly changing data requires careful handling.

7. What is a Lambda or custom authorizer?

Answer

A custom authorizer is application logic used by the gateway to make authorization decisions.

The authorizer receives identity information such as a token and returns an allow-or-deny result.

It is useful when:

  • Authorization logic is custom
  • Tokens use nonstandard formats
  • External entitlement systems must be queried
  • Access decisions depend on business attributes

Built-in JWT validation is usually simpler when standard tokens are available.

8. How do you secure an API Gateway?

Answer

Recommended controls include:

  • Require HTTPS.
  • Use strong identity-based authentication.
  • Validate JWT claims.
  • Apply least-privilege backend access.
  • Use WAF protection.
  • Configure throttling and quotas.
  • Validate request schemas.
  • Restrict CORS.
  • Use mTLS for partner APIs.
  • Use private integrations where appropriate.
  • Mask sensitive logs.
  • Monitor authentication failures.
  • Rotate API keys and certificates.
  • Enable audit logging.

9. How do you handle long-running requests behind an API Gateway?

Answer

Long-running processing should generally use an asynchronous pattern.

The gateway accepts the request and returns:

HTTP 202 Accepted

with a request or job ID.

The work is placed on a queue and processed by a background worker.

The client can:

  • Poll a status endpoint
  • Receive a webhook
  • Receive a WebSocket notification
  • Receive a message when processing completes

This avoids gateway and client timeout problems.

10. When should an API Gateway not be used?

Answer

An API Gateway may be unnecessary when:

  • A service is entirely internal and already protected by a service mesh.
  • A simple load balancer provides all required features.
  • The application has no formal API-consumer requirements.
  • Adding a gateway creates unnecessary latency and operational complexity.
  • Direct private service invocation is more suitable.

However, public, mobile, partner, and governed enterprise APIs usually benefit from a gateway.

Common Interview Follow-Up Questions

  • What is the difference between API Gateway and service mesh?
  • What is the difference between authentication and authorization?
  • How does JWT validation work?
  • What is a Lambda authorizer?
  • What is an API usage plan?
  • What is the difference between a quota and a rate limit?
  • How does API caching work?
  • How do you protect APIs from DDoS attacks?
  • How do you handle API versioning?
  • How do you expose a private API?
  • What is mTLS?
  • What is the Backend for Frontend pattern?
  • How do you troubleshoot HTTP 502 and 504 errors?
  • How do you implement canary deployment?
  • How do you monitor API performance?

Common Mistakes

Treating API Keys as Complete Authentication

API keys identify applications but may not securely identify users.

Allowing Unlimited Traffic

Without rate limits, clients can overwhelm backends and create unexpected cost.

Logging Tokens and Secrets

Authorization headers, API keys, and personal information should be masked.

Putting Business Logic in the Gateway

Complex business rules belong in backend services.

Using Wildcard CORS

Allowing every origin is unsafe for sensitive APIs.

Ignoring Backend Timeouts

Gateway and backend timeout values must be aligned.

Caching User Data Incorrectly

Improper cache keys can expose one user's response to another.

Returning Internal Exceptions

Stack traces and internal service details should not be exposed.

Missing API Versioning

Breaking changes can affect all existing clients.

Using One Gateway for Every Team Without Governance

A single oversized gateway can become an organizational bottleneck.

Troubleshooting API Gateway

HTTP 401 Unauthorized

Check:

  • Missing token
  • Expired token
  • Invalid signature
  • Incorrect issuer
  • Incorrect audience
  • Missing authentication configuration

HTTP 403 Forbidden

Check:

  • User permissions
  • Token scopes
  • IAM policy
  • Resource policy
  • API key restrictions
  • Network restrictions

HTTP 429 Too Many Requests

Check:

  • Client rate limit
  • Gateway throttle
  • Usage-plan quota
  • Backend concurrency
  • Account-level limits

HTTP 502 Bad Gateway

Check:

  • Invalid backend response
  • Incorrect integration configuration
  • Function exception
  • Response-format mismatch
  • Network connectivity
  • TLS errors

HTTP 504 Gateway Timeout

Check:

  • Backend processing time
  • Function timeout
  • Database latency
  • External API latency
  • Network routing
  • Long-running synchronous processing

High API Latency

Check:

  • Gateway processing time
  • Authorizer latency
  • Backend latency
  • Cold starts
  • Cache hit rate
  • Network location
  • Payload size

API Gateway Best Practices

  • Define APIs using OpenAPI.
  • Use consistent resource naming.
  • Require HTTPS.
  • Use OAuth 2.0 or identity-based authentication.
  • Validate JWT claims.
  • Apply least-privilege backend permissions.
  • Configure rate limits and quotas.
  • Validate requests at the gateway.
  • Use WAF protection.
  • Restrict CORS.
  • Use caching only when appropriate.
  • Propagate correlation and trace IDs.
  • Standardize error responses.
  • Avoid business logic in gateway policies.
  • Use asynchronous processing for long-running operations.
  • Monitor traffic, latency, errors, and throttling.
  • Use canary or blue-green deployments.
  • Separate environments.
  • Version APIs before introducing breaking changes.
  • Document deprecation timelines.
  • Test failure and security scenarios.
  • Review total gateway and observability cost.

Quick Revision

Topic Key Point
API Gateway Managed entry point for APIs
Reverse proxy Forwards requests to internal backends
Authentication Verifies caller identity
Authorization Verifies caller permissions
JWT Signed identity and authorization token
API key Identifies an API consumer
Rate limiting Controls request frequency
Throttling Rejects or delays excessive requests
Quota Controls long-term API usage
Caching Stores reusable responses
Transformation Changes request or response format
CORS Controls browser cross-origin access
OpenAPI Machine-readable API contract
mTLS Mutual certificate authentication
BFF Gateway optimized for one client type
WAF Filters malicious web requests
Canary release Sends limited traffic to a new version
HTTP 429 Rate limit exceeded
HTTP 502 Invalid gateway or backend response
HTTP 504 Backend timeout

Key Takeaways

  • An API Gateway provides a centralized entry point for clients accessing backend services.
  • It commonly handles routing, authentication, authorization, rate limiting, validation, caching, logging, and monitoring.
  • API Gateways are especially important in serverless and microservices architectures.
  • Authentication identifies the caller, while authorization determines permitted actions.
  • Rate limiting, throttling, quotas, and WAF protection help defend APIs and downstream systems.
  • API caching can improve performance but requires secure cache-key and invalidation design.
  • Long-running processes should use asynchronous APIs rather than keeping gateway connections open.
  • API Gateway and load balancers solve different problems and are often used together.
  • API Gateway manages external traffic, while a service mesh primarily manages internal service communication.
  • Secure API design requires least privilege, strong identity validation, controlled traffic, standardized errors, and comprehensive observability.