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
45 min · senior
senior

You are designing an API Gateway that acts as the single entry point for all client requests to a microservices backend in a startup with 50 million daily active users (DAU). The system must implement the Backend-for-Frontend (BFF) pattern to tailor APIs for different client types (mobile, web). The gateway must handle high throughput, enforce end-to-end encryption, and maintain a P99 latency under 200ms. The system should also support offline delivery mechanisms for mobile clients.

Constraints
  • End-to-end encryption of all client-server communication is mandatory
  • P99 latency for API responses must be under 200ms
  • Support offline delivery with sync mechanisms for mobile clients
  • Handle 50 million DAU with peak request rates up to 1 million RPS
  • BFF pattern requires separate tailored APIs per client type
  • Graceful degradation under partial microservice failures
📋
Guided Steps
1/5
Step 1
Choosing the API Gateway Technology and Deployment
Which technology and deployment model will you use for the API Gateway to handle 1M RPS with P99 < 200ms and support BFF pattern?
💡 Hint
Consider a scalable, low-latency reverse proxy that supports dynamic routing and protocol translation.
Key Decision
Use Envoy Proxy deployed as a Kubernetes Ingress Controller with horizontal pod autoscaling - Envoy supports HTTP/2, gRPC, and dynamic routing essential for BFF and scales linearly with pods.
Interviewer Expectation
Mid: Names Envoy or NGINX. Senior: Explains Envoy’s dynamic routing, HTTP/2 multiplexing, and integration with service mesh for observability and resilience.
⚠️Common Wrong Answer
Using a monolithic API Gateway like Kong without autoscaling - leads to bottlenecks and inability to meet 1M RPS and latency SLAs.
Step 2
Implementing the BFF Pattern for Client-Specific APIs
How will you implement the BFF pattern to serve different client types with tailored APIs while maintaining maintainability and scalability?
💡 Hint
Think about separating client-specific logic and aggregating microservice responses efficiently.
Key Decision
Implement separate BFF microservices per client type (e.g., mobile BFF, web BFF) using Node.js with GraphQL aggregation - GraphQL enables flexible tailored responses and reduces over-fetching.
Interviewer Expectation
Mid: Mentions separate BFF services. Senior: Explains GraphQL’s role in aggregating multiple microservice calls into one tailored response and caching strategies per client.
⚠️Common Wrong Answer
Single generic API Gateway endpoint for all clients - causes over-fetching, increased latency, and complex client-side logic.
Step 3
Ensuring End-to-End Encryption and Security
How will you enforce end-to-end encryption and secure client-server communication across the API Gateway and microservices?
💡 Hint
Consider TLS termination points and mutual TLS between components.
Key Decision
Terminate TLS at Envoy with mutual TLS (mTLS) between Envoy and microservices using SPIFFE identities - ensures encryption in transit and strong service authentication.
Interviewer Expectation
Mid: Mentions TLS termination at gateway. Senior: Details mTLS with SPIFFE for identity, automated certificate rotation, and zero-trust security model.
⚠️Common Wrong Answer
Terminate TLS only at the gateway and use plaintext internally - exposes internal traffic to interception and breaks end-to-end encryption.
Step 4
Designing Offline Delivery and Sync Mechanism
How will you design the offline delivery and synchronization mechanism to support mobile clients that may be disconnected for extended periods?
💡 Hint
Think about event sourcing, message queues, and client-side state reconciliation.
Key Decision
Use Apache Kafka with topic partitioning by client ID for event sourcing, combined with Redis for client sync state caching - enables ordered event replay and efficient cursor-based sync on reconnect.
Interviewer Expectation
Mid: Names Kafka for messaging. Senior: Explains partition key choice for ordering, Redis TTL caching for offline detection, and cursor-based incremental sync to minimize data transfer.
⚠️Common Wrong Answer
HTTP polling for sync - causes excessive load and latency spikes at 50M DAU.
Step 5
Handling Partial Microservice Failures Gracefully
How will the API Gateway and BFF services handle partial failures in downstream microservices to maintain availability and meet latency SLAs?
💡 Hint
Consider circuit breakers, fallback responses, and request timeouts.
Key Decision
Integrate Envoy’s circuit breaker and retry policies with BFF fallback logic returning cached or default responses - prevents cascading failures and maintains P99 latency under 200ms.
Interviewer Expectation
Mid: Mentions retries and timeouts. Senior: Explains circuit breaker thresholds, fallback cache usage, and how to degrade gracefully without user impact.
⚠️Common Wrong Answer
No failure handling - leads to cascading failures and SLA violations.
🔌
API Design Challenge
Sketch 3 core API endpoints for the API Gateway BFF: one for client request submission, one for client data synchronization (offline support), and one for client acknowledgment of received data.
Hints
  • How does the client send requests and receive tailored responses?
  • How does the client synchronize state after offline periods?
  • How does the client acknowledge successful receipt to enable server-side cleanup?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of Envoy Proxy with autoscaling to handle 1M RPS and P99 < 200ms
  • Implementation of BFF pattern with separate microservices per client type
  • End-to-end encryption with mutual TLS between gateway and microservices
  • Offline delivery using Kafka with partitioning by client ID
  • Graceful failure handling with circuit breakers and fallback responses
Good to Have - 30%
  • GraphQL for flexible aggregation in BFF services
  • Redis caching for offline client state and sync optimization
  • Cursor-based incremental sync APIs
  • Kubernetes autoscaling for dynamic load management
Bonus - 10%
  • Use of SPIFFE for identity management in mTLS
  • Detailed fallback strategies for degraded service modes
Anti-patterns to Avoid
Monolithic API Gateway without autoscaling - causes bottlenecks and SLA breaches under 1M RPS, leading to system failure under load
Single generic API endpoint for all clients - leads to over-fetching, increased latency, and poor client experience due to lack of tailored responses
Terminating TLS only at gateway and using plaintext internally - breaks end-to-end encryption and exposes internal traffic to interception
HTTP polling at 50M DAU: 50 million reconnects per minute just to check for messages - collapses under load and causes latency spikes
✅
Model Answer
▼ Reveal

The API Gateway uses Envoy Proxy deployed on Kubernetes with autoscaling to handle 1 million RPS and maintain P99 latency under 200ms. Separate BFF microservices per client type (mobile, web) are implemented using Node.js and GraphQL to provide tailored APIs and efficient aggregation. End-to-end encryption is enforced via TLS termination at Envoy and mutual TLS with SPIFFE identities between Envoy and microservices. Offline delivery is supported using Apache Kafka with client ID partitioning for ordered event sourcing and Redis caching for client sync state. Envoy circuit breakers and retry policies combined with BFF fallback logic ensure graceful degradation under partial failures. Cursor-based incremental sync APIs minimize data transfer for offline clients.

Key Decisions
  • Use Envoy Proxy for API Gateway with Kubernetes autoscaling to meet 1M RPS and latency SLAs
  • Implement BFF pattern with separate microservices per client type using Node.js and GraphQL for tailored responses
  • Enforce end-to-end encryption with TLS termination at Envoy and mutual TLS using SPIFFE identities internally
  • Use Apache Kafka with client ID partitioning for event sourcing and offline delivery support
  • Cache client sync state in Redis with TTL to enable efficient offline detection and incremental sync
  • Configure Envoy circuit breakers and retry policies with BFF fallback logic to handle partial microservice failures gracefully
  • Design cursor-based incremental sync APIs to minimize data transfer and latency for offline clients
  • Deploy Kubernetes Horizontal Pod Autoscaler for Envoy and BFF pods to elastically scale with traffic
  • Envoy Proxy as API Gateway with Kubernetes autoscaling - supports 1M RPS and low latency
  • Separate BFF microservices per client type using Node.js and GraphQL - tailored APIs and efficient aggregation
  • Mutual TLS with SPIFFE identities between Envoy and microservices - enforces end-to-end encryption and zero-trust security
  • Apache Kafka with client ID partitioning for event sourcing and offline delivery - ordered, scalable message replay
  • Redis with TTL-based client state caching - enables efficient offline detection and sync
  • Envoy circuit breakers and retry policies combined with BFF fallback logic - graceful degradation under partial failures
  • Cursor-based incremental sync APIs to minimize data transfer and latency for offline clients
  • Kubernetes Horizontal Pod Autoscaler for BFF and Envoy pods - elastic scaling to meet traffic spikes

Practice

(1/5)
1. A deployment system must ensure zero downtime during releases by switching traffic instantly between two identical environments. Which deployment strategy best fits this requirement?
easy
A. Rolling deployment updating servers one by one
B. Canary deployment with gradual traffic shifting to new version
C. Feature flags toggling new features on the same environment
D. Blue-Green deployment with instant switch of load balancer target

Solution

  1. Step 1: Identify zero downtime requirement

    Blue-Green deployment uses two identical environments and switches traffic instantly, ensuring zero downtime.

  2. Step 2: Eliminate other options

    Canary is gradual, not instant; Feature flags don't switch entire environments; Rolling updates cause partial downtime.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Blue-Green switches environments instantly for zero downtime [check]
Hint: Instant switch between identical environments is Blue-Green [OK]
Common Mistakes:
2. A distributed system needs to monitor request latency and error rates in near real-time to trigger alerts. Which observability component is best suited to handle this requirement?
easy
A. A batch job that processes logs nightly to generate reports
B. Centralized logging system that aggregates all logs for offline analysis
C. Distributed tracing system that records end-to-end request paths for debugging
D. Metrics collection system that aggregates and visualizes numerical data over time

Solution

  1. Step 1: Identify the need for near real-time numerical data aggregation

    Metrics systems collect numerical data like latency and error rates continuously and support alerting.

  2. Step 2: Eliminate logging and tracing for this use case

    Logging is better for detailed event records, not real-time aggregation; tracing is for request path debugging, not metrics aggregation.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Metrics aggregate numerical data for alerts and dashboards [check]
Hint: Metrics track numbers over time for alerts [check]
Common Mistakes:
3. Without the message queue (Kafka) in the architecture, what exactly breaks when Alice sends a message to Bob during a partial regional outage?
medium
A. Messages are buffered locally on Alice's client until Bob reconnects
B. Alice's message is immediately delivered but Bob's client shows duplicate messages
C. Alice's send blocks waiting for Bob's server response; if Bob's server crashes, the message is lost with no retry
D. The system automatically retries sending messages indefinitely without blocking

Solution

  1. Step 1: Understand Kafka's role in decoupling

    Kafka buffers messages asynchronously, preventing blocking and enabling retries during outages.

  2. Step 2: Analyze failure without Kafka

    Without Kafka, synchronous calls block sender until receiver responds; if receiver crashes, message is lost with no retry (B). However, buffering on client (C) is incorrect as buffering is server-side.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    No Kafka -> synchronous send blocks and message loss on receiver crash [check]
Hint: No Kafka -> send blocks, no retry, message lost on crash [check]
Common Mistakes:
4. In a primary-replica system, what exactly breaks if the replication log (WAL) on the primary is lost before being sent to replicas?
medium
A. Replicas request full data snapshot from primary, causing high load and delayed recovery
B. Primary blocks all writes until WAL is restored, causing system-wide write unavailability
C. Primary loses committed transactions permanently, causing data loss and inconsistency
D. Replicas continue serving stale reads but cannot apply new writes, causing data divergence

Solution

  1. Step 1: Understand WAL role in replication

    WAL is the source of truth for replicas to catch up incrementally.

  2. Step 2: Trace failure impact

    If WAL is lost, replicas cannot catch up incrementally and must request full snapshot, causing load and delay.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Lost WAL -> replicas request full snapshot -> recovery delay [check]
Hint: Lost WAL -> full snapshot fetch delays recovery [check]
Common Mistakes:
5. If the Booking Service loses connectivity to the Calendar Availability Service during booking confirmation, what is the most likely failure mode experienced by the user?
medium
A. The booking is queued locally and confirmed later without user notification
B. The booking request times out and the user sees an error without confirmation
C. The booking is confirmed but the calendar is not updated, causing double bookings
D. The system automatically retries and confirms booking without user delay

Solution

  1. Step 1: Trace failure impact on booking flow

    Loss of connectivity prevents immediate calendar update, risking inconsistency.

  2. Step 2: Analyze failure handling

    Immediate confirmation without calendar update (A) risks double bookings; timeout with error (B) hurts UX; automatic retry without delay (D) is unrealistic under network failure. Local queuing (C) allows eventual consistency with delayed confirmation.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Local queuing delays confirmation but prevents data loss [check]
Hint: Booking queues locally on calendar service failure, delaying confirmation [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