Bird
Raised Fist0

API Gateway as Microservices Entry Point - BFF Pattern

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
API Gateway as Microservices Entry Point - BFF Pattern
Design an API Gateway using Backend-for-Frontend pattern to serve microservices efficiently at scale
mediumMicroservices InfrastructureFreq: common
⚙️
Functional Requirements
  • Route client requests to appropriate microservices via the API Gateway
  • Implement Backend-for-Frontend (BFF) pattern to tailor APIs per client type (web, mobile)
  • Aggregate responses from multiple microservices to reduce client round-trips
  • Handle authentication and authorization centrally at the gateway
  • Support request throttling and rate limiting per client
  • Provide observability (metrics, logging, tracing) for requests passing through
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU)
  • Achieve 99.99% availability SLA for the gateway
  • Ensure 100ms P99 latency for API Gateway response time under peak load
  • Handle peak write QPS of approximately 925K requests/sec
  • Scale horizontally with zero downtime deployments
❓
Clarifying Questions to Ask
  • What are the client types (web, mobile, IoT) and their traffic proportions?
  • What is the expected request size and response size per API call?
  • Are there any SLAs for request retries or error handling at the gateway?
  • Is the gateway responsible for protocol translation (e.g., REST to gRPC)?
  • What are the security requirements for authentication and authorization?
  • Should the gateway support synchronous aggregation or async fan-out patterns?
Out of Scope
✗ Design of individual microservices behind the gateway
✗ Detailed authentication protocol design (e.g., OAuth flows)
✗ Client-side caching strategies
✗ Data storage schema for microservices
📌
Assumptions
  • 2 billion DAU
  • 40 API requests per user per day
  • Average request payload size: 100 bytes
  • Average response payload size: 1 KB
⚡
QPS Calculation
write qps2,000,000,000 × 40 / 86,400 ≈ 925,926 requests/sec
peak write qpsAssuming 2× peak factor → 1,851,852 requests/sec
read qpsAssuming 3× read amplification → 2,777,778 requests/sec
💾
Storage Estimate
daily storage bytes925,926 req/sec × 100 bytes × 86,400 sec ≈ 8 TB/day
retention days7
total storage with replication8 TB × 7 days × 3 replicas = 168 TB
🖥️
Server Estimate
api gateway serversAssuming 10,000 req/sec per server → 185 servers at peak
load balancers3 redundant NGINX or Envoy instances per region for HA
🏗️
Architecture Diagram
Architecture Diagram
      +----------------------+
      |      Clients         |
      |   (Web, Mobile, IoT) |
      +---------+------------+
                | HTTPS REST/gRPC
      +---------v------------+
      |   API Gateway BFF    |
      | (Envoy + Custom BFF)|
      +---------+------------+
        |          |          |
   +----+          |          +----+
   |               |               |
   v               v               v
Auth Service  Aggregation Service  Rate Limiter
   |               |               |
   +-------+-------+---------------+
           |
           v
    +------------------+
    |   Microservices   |
    |  (User, Order,   |
    |     etc)         |
    +------------------+
🧩
Components
API Gateway BFF
Entry point for all client requests; implements Backend-for-Frontend pattern to tailor APIs per client type
Why thisEnvoy proxy with custom BFF layer enables protocol translation, request aggregation, and client-specific logic with low latency
Why notNGINX alone lacks native support for dynamic request aggregation and protocol translation at scale
Auth Service
Centralized authentication and authorization for all incoming requests
Why thisKeycloak provides scalable OAuth2 and OpenID Connect support with token introspection and caching
Why notCustom auth service risks security flaws and does not scale easily without mature token management
Aggregation Service
Aggregates data from multiple microservices to reduce client round-trips
Why thisGraphQL server enables flexible, client-driven queries and efficient data fetching
Why notREST aggregation at gateway leads to multiple sequential calls and higher latency
Rate Limiter
Enforces per-client and global request throttling to protect backend services
Why thisRedis with token bucket algorithm provides sub-millisecond latency and distributed rate limiting
Why notIn-memory local rate limiting cannot coordinate across multiple gateway instances
Load Balancer
Distributes incoming client requests evenly across API Gateway instances
Why thisAWS ALB or GCP Load Balancer supports HTTP/2, TLS termination, and health checks at scale
Why notDNS round-robin lacks health checks and fine-grained traffic control
Microservices
Business logic services handling domain-specific operations
Why thisSpring Boot or Node.js microservices provide modular, independently deployable units
Why notMonolithic backend would not scale or allow independent deployments
🔄
Data Flow
1
Client → Load Balancer
Client sends HTTPS request
Load balancer terminates TLS and forwards to API Gateway
2
Load Balancer → API Gateway BFF
Route request based on client type and endpoint
BFF applies client-specific logic and protocol translation
3
API Gateway BFF → Auth Service
Validate authentication token
Reject unauthorized requests early
4
API Gateway BFF → Rate Limiter
Check and enforce request rate limits
Throttle or reject if limits exceeded
5
API Gateway BFF → Aggregation Service
Fetch and aggregate data from multiple microservices
Reduce client round-trips and tailor response
6
Aggregation Service → Microservices
Call domain microservices for data
Parallel calls to reduce latency
7
Aggregation Service → API Gateway BFF
Return aggregated response
BFF formats response per client needs
8
API Gateway BFF → Client
Send final response
Complete the request-response cycle

Practice

(1/5)
1. If the API gateway loses the logic to parse the X-API-Version header, what is the exact failure observed by clients using header-based versioning?
medium
A. Clients' requests are routed to the latest version regardless of header, breaking older clients
B. Clients get 404 Not Found errors because the gateway cannot route requests
C. Clients receive responses from the default version, causing silent compatibility issues
D. Clients experience increased latency as the gateway retries version parsing repeatedly

Solution

  1. Step 1: Understand gateway header parsing role

    The gateway uses X-API-Version header to route requests; losing parsing logic means it cannot determine version.

  2. Step 2: Trace failure consequences

    Without parsing, the gateway may retry or fallback inefficiently, causing increased latency rather than immediate errors or silent fallback.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Missing header parsing causes retries and latency spikes [check]
Hint: Lost header parsing -> gateway retries, causing latency [check]
Common Mistakes:
2. For a leaderboard system requiring global ranking with millions of concurrent updates, which architecture is best to ensure low latency and eventual consistency?
medium
A. Use a single Redis instance with sorted sets and synchronous writes
B. Store all scores in a distributed SQL database with strong consistency
C. Partition leaderboard by user region with multiple Redis clusters and merge results asynchronously
D. Use a NoSQL store with eventual consistency and batch ranking computation

Solution

  1. Step 1: Evaluate single Redis instance

    Single Redis can't handle millions of writes with low latency due to CPU and memory limits.

  2. Step 2: Consider partitioning by region

    Partitioning reduces load per cluster, allows parallel writes, and merging asynchronously balances latency and consistency.

  3. Step 3: Distributed SQL and NoSQL drawbacks

    Distributed SQL has high write latency; NoSQL batch ranking delays real-time queries.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Partitioned Redis clusters with async merge balance scale and latency [check]
Hint: Partition and merge asynchronously for scale and low latency [check]
Common Mistakes:
3. If the Market Data Feed component crashes and stops publishing updates, what is the exact failure observed by external clients subscribing to real-time stock prices?
medium
A. Clients receive stale prices indefinitely with no indication of failure
B. Clients receive partial updates but with delayed timestamps causing confusion
C. Clients receive an error message and automatic reconnection attempts begin
D. Clients continue receiving cached data from the Matching Engine without updates

Solution

  1. Step 1: Understand Market Data Feed failure impact

    When Market Data Feed crashes, it stops pushing updates; clients detect connection loss and receive error events triggering reconnection.

  2. Step 2: Eliminate other options

    Clients receive stale prices indefinitely with no indication of failure is wrong because clients detect connection loss; Clients receive partial updates but with delayed timestamps causing confusion is wrong because partial updates don't occur without feed; Clients continue receiving cached data from the Matching Engine without updates is wrong because Matching Engine doesn't serve cached market data.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Feed crash -> clients get error + reconnect attempts [check]
Hint: Feed crash triggers client error and reconnect [check]
Common Mistakes:
4. You must design a load balancer for a global web app that requires session stickiness and fault tolerance. Which approach is best?
medium
A. Use IP Hash to ensure session stickiness but risk uneven load distribution
B. Use Round Robin to evenly distribute requests without session affinity
C. Use Least Connections with a centralized session store for stickiness
D. Use Weighted Round Robin with weights adjusted dynamically per server health

Solution

  1. Step 1: Identify session stickiness requirement

    Session stickiness requires requests from the same client to reach the same server to maintain session state.

  2. Step 2: Evaluate options for stickiness and fault tolerance

    Round Robin ignores stickiness; Least Connections needs external session store adding complexity; Weighted Round Robin adjusts load but not stickiness. IP Hash provides stickiness by hashing client IP.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    IP Hash ensures session stickiness but may cause uneven load distribution [check]
Hint: IP Hash ensures stickiness but risks uneven load distribution [check]
Common Mistakes:
5. For a metrics system that must support both high-frequency real-time alerts and long-term trend analysis, which architecture is best suited?
medium
A. Use a hybrid push-pull model: agents push metrics to a buffer, and the server pulls aggregated data for analysis
B. Use a pure push model where agents send metrics directly to storage without server polling
C. Use a pure pull model where the monitoring server scrapes all metrics on demand
D. Use a peer-to-peer push model where agents exchange metrics without a central server

Solution

  1. Step 1: Analyze pull-only model

    Pull-only (A) struggles with high-frequency alerts due to scrape delays and network spikes.

  2. Step 2: Analyze push-only and peer-to-peer

    Push-only (C) lacks centralized control for trend analysis; peer-to-peer (D) complicates consistency and aggregation.

  3. Step 3: Hybrid push-pull benefits

    Hybrid (B) buffers metrics for real-time alerts and allows server-side pulls for efficient long-term analysis.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Hybrid push-pull balances real-time and batch needs [check]
Hint: Hybrid push-pull fits real-time and batch analysis best [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard