Bird
Raised Fist0

API Gateway as Microservices Entry Point - BFF Pattern

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
API Gateway BFF

Receives client HTTPS request

API Gateway BFF accepts and parses incoming client request

Protocol:HTTPS
BeforeClient has sent a new HTTPS request
AfterAPI Gateway BFF has received and parsed the request
Rate Limiter

Checks request rate limits

Rate Limiter verifies client has not exceeded allowed request quota

Protocol:Internal REST
BeforeAPI Gateway BFF has parsed request but not yet rate limited
AfterRequest passed rate limiting or rejected if quota exceeded
Auth Service

Validates authentication token

Auth Service confirms client identity and token validity

Protocol:Internal REST
BeforeRequest passed rate limiting but not authenticated
AfterRequest authenticated or rejected if token invalid
Load Balancer

Routes request to appropriate microservice

Load Balancer selects healthy Microservices instance for request

Protocol:Internal REST
BeforeRequest authenticated but not yet routed to microservices
AfterRequest forwarded to selected Microservices instance
Microservices

Processes business logic

Microservices handle domain logic and prepare partial response

Protocol:Internal REST
BeforeRequest received by Microservices instance
AfterPartial response generated for aggregation
Aggregation Service

Aggregates data from multiple microservices

Aggregation Service combines responses into unified payload

Protocol:Internal REST
BeforePartial responses available from Microservices
AfterUnified response ready for API Gateway BFF
API Gateway BFF

Sends aggregated response to client

API Gateway BFF returns final response over HTTPS

Protocol:HTTPS
BeforeAggregated response ready at API Gateway BFF
AfterClient receives final response
🏗️
Architecture Diagram
Architecture Diagram
┌─────────┐
│ Client  │
└────┬────┘
     │ HTTPS
     ▼
┌───────────────┐
│ API Gateway   │
│ BFF           │
└────┬──────────┘
     │ Internal REST
     ▼
┌───────────────┐
│ Rate Limiter  │
└────┬──────────┘
     │ Internal REST
     ▼
┌───────────────┐
│ Auth Service  │
└────┬──────────┘
     │ Internal REST
     ▼
┌───────────────┐
│ Load Balancer │
└────┬──────────┘
     │ Internal REST
     ▼
┌───────────────┐
│ Microservices │
└────┬──────────┘
     │ Internal REST
     ▼
┌───────────────┐
│ Aggregation   │
│ Service       │
└────┬──────────┘
     │ HTTP Response
     ▼
┌───────────────┐
│ API Gateway   │
│ BFF           │
└────┬──────────┘
     │ HTTPS Response
     ▼
┌─────────┐
│ Client  │
└─────────┘
Design Rationale

This architecture uses an API Gateway BFF as the single entry point for client requests. Incoming HTTPS requests first hit the API Gateway BFF, which enforces rate limiting to prevent abuse. Next, the Auth Service validates client tokens to ensure secure access. The Load Balancer then routes requests to appropriate Microservices instances that handle domain-specific logic. Responses from these microservices are sent to the Aggregation Service, which combines them into a unified payload. Finally, the API Gateway BFF returns the aggregated response to the client. This vertical flow ensures modularity, security, and scalability by separating concerns and centralizing client interaction.

Primary Focus

✓

Practice

(1/5)
1. A monitoring system must detect when a metric exceeds a fixed limit for 5 consecutive minutes and trigger an alert. Which component is best suited to implement this logic?
easy
A. Threshold-based alerting component that evaluates metric values against static limits
B. Event ingestion pipeline that collects raw metric data without evaluation
C. Composite alert processor that combines multiple alert conditions into one
D. Anomaly detection engine using machine learning to identify unusual patterns

Solution

  1. Step 1: Identify alerting logic type

    The requirement is to detect when a metric exceeds a fixed limit for a duration, which is a classic threshold alert scenario.

  2. Step 2: Match component to logic

    Threshold-based alerting components are designed to evaluate metrics against static limits over time windows, unlike anomaly detection which looks for statistical deviations.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Threshold alerting matches fixed limit checks over time [check]
Hint: Fixed limit over time -> threshold alert component [check]
Common Mistakes:
2. If the distributed lock service is unavailable, what exactly breaks in the hotel booking system's reservation flow?
medium
A. Reservations proceed normally but double bookings increase due to lack of coordination
B. Reservation requests block indefinitely waiting for locks, causing user timeouts and failed bookings
C. Inventory service marks rooms as available incorrectly, causing UI to show wrong availability
D. Payment processing fails because it depends on the lock service for transaction ordering

Solution

  1. Step 1: Identify lock service role in reservation flow

    The lock service ensures exclusive access to room inventory during reservation to prevent double booking.

  2. Step 2: Trace failure impact

    Without the lock service, Inventory cannot reliably mark rooms as unavailable, leading to stale or incorrect availability states shown to users (Inventory service marks rooms as available incorrectly, causing UI to show wrong availability). Reservations may still proceed but with inconsistent inventory state. Blocking indefinitely (Reservation requests block indefinitely waiting for locks, causing user timeouts and failed bookings) is unlikely as fallback mechanisms exist. Payment processing (Payment processing fails because it depends on the lock service for transaction ordering) is independent of locking. Double bookings (Reservations proceed normally but double bookings increase due to lack of coordination) may increase but the immediate failure is incorrect inventory state.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Lock service failure causes stale inventory availability state [check]
Hint: Lock service failure -> stale inventory state, not immediate booking block [check]
Common Mistakes:
3. If the MongoDB cluster loses the shard key index on a sharded collection, what exactly breaks in query routing and data consistency?
medium
A. Queries continue normally but writes fail silently causing data loss.
B. The mongos router cannot route queries to correct shards, causing scatter-gather queries and potential stale reads.
C. Shard servers reject all queries until the index is rebuilt, causing total downtime.
D. Data replication stops between shards leading to inconsistent replicas.

Solution

  1. Step 1: Role of shard key index

    Shard key index is critical for routing queries to correct shards and maintaining data partitioning.

  2. Step 2: Impact of losing shard key index

    Without the index, shards cannot serve queries properly and reject operations until index rebuild, causing downtime.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Shard key index loss causes shard query rejection and downtime [check]
Hint: Shard key index loss causes shard query rejection, not silent failure [check]
Common Mistakes:
4. If Kafka's offset commit mechanism is disabled, what failure occurs when a consumer crashes after processing messages?
medium
A. Messages are reprocessed on restart, causing duplicates
B. Kafka automatically reassigns partitions to other consumers
C. Messages are lost because Kafka deletes them immediately
D. Consumer cannot rejoin the group due to missing offsets

Solution

  1. Step 1: Understand offset commit role

    Offset commits record progress; disabling commits means no progress saved.

  2. Step 2: Trace failure impact

    On crash, consumer restarts from last committed offset (which is old), reprocessing messages and causing duplicates.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No offset commit -> consumer may fail to rejoin group due to missing offsets [check]
Hint: No offset commit -> consumer rejoin failure [OK]
Common Mistakes:
5. At 10x traffic scale, which component is most likely to fail first and why?
hard
A. The chat servers because WebSocket connections are stateful and cannot be resharded easily
B. The load balancer because it cannot distribute connections evenly at high scale
C. The database because it cannot handle increased write throughput without sharding
D. The CDN because cache invalidation delays increase latency

Solution

  1. Step 1: Identify stateful bottlenecks

    Chat servers maintain WebSocket connections statefully, binding clients to specific servers.

  2. Step 2: Scaling challenges

    At 10x scale, adding servers doesn't move existing connections, causing uneven load and resource exhaustion.

  3. Step 3: Why others fail later

    Databases can be sharded (The database because it cannot handle increased write throughput without sharding), load balancers scale horizontally (The load balancer because it cannot distribute connections evenly at high scale), and CDNs handle scale well (The CDN because cache invalidation delays increase latency).

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Stateful WebSocket servers -> resharding limits cause first failure [check]
Hint: Stateful WebSocket servers fail first at scale due to reshard limits [OK]
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