Skip to content
Interview Prep Buddy LogoInterview Prep Buddy

06 — API Gateway

06 — API Gateway

Section titled “06 — API Gateway”

An API Gateway is a single entry point for all client requests to a backend system. It handles cross-cutting concerns like authentication, rate limiting, routing, and aggregation — keeping backend services simple.

Analogy: An API Gateway is like a reception desk at a large office building. Visitors don’t wander through hallways looking for the right person — they go to the desk, get authenticated, and are directed to the correct office.

Problem Statement

Section titled “Problem Statement”

Without an API Gateway:

  • Every client must know the location of every microservice
  • Cross-cutting concerns (auth, logging, rate limiting) are duplicated across services
  • Clients make multiple round-trips to gather related data
  • Protocol translation (HTTP → gRPC → WebSocket) must be handled by each service
  • Changing service URLs or splitting services breaks clients

Architecture Overview

Section titled “Architecture Overview”
flowchart LR
    subgraph Clients["Clients"]
        Web["Web App"]
        Mobile["Mobile App"]
        Third["Third-Party API"]
    end


    subgraph Gateway["API Gateway"]
        Auth["Authentication"]
        Rate["Rate Limiting"]
        Route["Request Routing"]
        Aggregate["Response Aggregation"]
        Transform["Protocol Translation"]
    end


    subgraph Services["Backend Services"]
        Users["User Service"]
        Orders["Order Service"]
        Payment["Payment Service"]
        Notification["Notification Service"]
    end


    Web & Mobile & Third --> Gateway
    Gateway --> Users & Orders & Payment & Notification


    style Clients fill:#f59e0b,color:#fff
    style Gateway fill:#7c3aed,color:#fff
    style Services fill:#059669,color:#fff

API Gateway Responsibilities

Section titled “API Gateway Responsibilities”
ResponsibilityDescriptionExample
Request RoutingRoute to correct service/users/* → User Service
AuthenticationVerify identityValidate JWT, OAuth tokens
Rate LimitingPrevent abuse100 req/min per user
CachingCache frequent responsesCache /products/popular
AggregationCombine multiple service responsesGet user + orders in one call
Protocol TranslationConvert between protocolsREST → gRPC, HTTP → WebSocket
Request/Response TransformationModify payloadsAdd headers, rename fields
Circuit BreakingFail fast when downstream is downReturn cached/fallback response
Logging & MonitoringCentralized observabilityLog all API calls, metrics
API VersioningSupport multiple versions/v1/users, /v2/users

Request Flow

Section titled “Request Flow”
sequenceDiagram
    participant Client as Client App
    participant GW as API Gateway
    participant Auth as Auth Service
    participant S1 as Service A
    participant S2 as Service B


    Client->>GW: GET /api/orders/123
    GW->>Auth: Validate token
    Auth-->>GW: Valid: user=456


    GW->>GW: Check rate limit (OK)


    GW->>S1: GET /orders/123 (internal)
    S1-->>GW: Order data


    GW->>S2: GET /users/456 (aggregate)
    S2-->>GW: User data


    GW->>GW: Merge responses
    GW-->>Client: 200 { order + user }

API Gateway Patterns

Section titled “API Gateway Patterns”
PatternDescriptionProsCons
Single GatewayOne gateway for all clientsSimple, centralizedSingle point of failure
Multiple GatewaysSeparate gateways per client type (mobile, web, IoT)Optimized per clientDuplicated logic
BFF (Backend for Frontend)Each client has its own backend gatewayTailored responsesMultiple gateways to maintain
Gateway per TeamEach team owns their gatewayTeam autonomyInconsistent patterns

API Versioning Strategies

Section titled “API Versioning Strategies”
flowchart TB
    Version["Versioning Strategy"] --> URI["URI-based<br/>/v1/users, /v2/users<br/>Simple, widely used"]
    Version --> Header["Header-based<br/>Accept: app/vnd.myapp.v2+json<br/>Clean URLs"]
    Version --> Query["Query param<br/>/users?version=2<br/>Easy to test"]
    Version --> Contract["Contract-based<br/>GraphQL schema evolution<br/>No versioning needed"]


    style Version fill:#7c3aed,color:#fff
    style URI fill:#3b82f6,color:#fff
    style Header fill:#059669,color:#fff
    style Query fill:#f59e0b,color:#fff
    style Contract fill:#ef4444,color:#fff
Section titled “Popular API Gateway Solutions”
GatewayTypeKey Features
AWS API GatewayManagedREST/HTTP/WebSocket, Lambda proxy, caching
KongOpen-sourcePlugin ecosystem, Lua-based, DB-backed
NGINX PlusReverse proxyHigh performance, Lua scripting
TraefikCloud-nativeAuto-service discovery, Let’s Encrypt
Apollo GatewayGraphQLFederated GraphQL schema stitching
Zuul (Spring Cloud)Java/JVMNetflix OSS, filter-based

Trade-offs

Section titled “Trade-offs”
DecisionProsCons
Single gatewaySimple, single URLSPOF, can become monolith
BFF patternOptimal per client experienceN gateways to maintain
GraphQL gatewayClient-driven queriesComplex caching, N+1 risks
Edge gateway (CDN)Global low latencyLimited compute, cost

Scaling Strategies

Section titled “Scaling Strategies”
StrategyDescription
Horizontal scalingStateless gateways behind a load balancer
Regional deploymentGateway per region, route by latency
Gateway federationSplit gateway by domain (orders, users, payments)
Edge deploymentDeploy gateway logic at CDN edge (Cloudflare Workers)
Circuit breakingFail fast when services are down, don’t block the gateway

Interview Questions

Section titled “Interview Questions”
  1. What problems does an API Gateway solve?
  2. What’s the difference between a single gateway and BFF pattern?
  3. How does an API Gateway handle authentication?
  4. How would you design rate limiting at the gateway level?
  5. What happens when the API Gateway goes down?

Real-World Examples

Section titled “Real-World Examples”
SystemGateway Approach
NetflixZuul gateway → Spring Cloud Gateway, BFF per device type
AmazonMultiple internal gateways per domain team
ShopifyBFF pattern — separate graphql endpoints for storefront, admin, mobile
GitHubSingle public REST API gateway + GraphQL v4 gateway

In Simple Words

Section titled “In Simple Words”
  • API Gateway = single front door for all microservices — auth, routing, rate limiting in one place
  • It aggregates responses so clients make one call instead of many
  • BFF pattern = each client type (web, mobile, IoT) gets its own optimized gateway
  • The gateway should be stateless — scale it horizontally like any other service
  • Don’t put business logic in the gateway — keep it to cross-cutting concerns only
  • A dead gateway takes down your whole system — make it highly available