Bird
Raised Fist0

Rate Limiting at Different Layers - API Gateway, Service, Database

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
API Gateway Rate Limiter

Checks client request rate limit

Queries Redis for client quota and increments counter if allowed

Protocol:Redis GET/INCR
BeforeClient request received, no rate limit checked yet
AfterClient quota counter incremented; request allowed or rejected
Service Layer Rate Limiter

Checks per-user rate limit within service

Queries Redis for user-specific limit and increments counter if allowed

Protocol:Redis GET/INCR
BeforeRequest passed API Gateway rate limit
AfterUser quota counter incremented; request allowed or rejected
Database Layer Rate Limiter

Checks DB access rate limit to prevent overload

Queries Redis for DB access count and increments if allowed

Protocol:Redis GET/INCR
BeforeRequest passed service layer rate limit
AfterDB access counter incremented; request allowed or rejected
Redis Cluster

Stores and updates rate limit counters

Handles GET and INCR commands from all rate limiter layers

Protocol:Redis GET/INCR
BeforeCounters reflect previous request states
AfterCounters updated atomically for current request
Config Mgmt Service

Provides rate limit configuration to all layers

Serves config updates to API Gateway, Service, and DB limiters

Protocol:Config Fetch
BeforeRate limiters use cached config
AfterRate limiters updated with latest config values
🏗️
Architecture Diagram
Architecture Diagram
┌─────────┐
│ Client  │
└────┬────┘
     │ HTTPS Request
     ▼
┌───────────────────────────┐
│ API Gateway Rate Limiter  │
│  (checks client quota)    │
└────┬──────────────────────┘
     │ Redis GET/INCR
     ▼
┌───────────────────────────┐
│ Service Layer Rate Limiter│
│  (checks per-user limits) │
└────┬──────────────────────┘
     │ Redis GET/INCR
     ▼
┌───────────────────────────┐
│ Database Layer Rate Limiter│
│  (protects DB from overload)│
└────┬───────────────────────┘
     │ Redis GET/INCR
     ▼
┌───────────────┐
│ Redis Cluster │
└────┬──────────┘
     │ Config Fetch
     ▼
┌───────────────────────────┐
│ Config Mgmt Service       │
└───────────────────────────┘
Design Rationale

This architecture enforces rate limiting at three distinct layers: API Gateway, Service Layer, and Database Layer. Each layer queries the Redis Cluster to atomically check and increment counters representing usage quotas. The API Gateway Rate Limiter protects the system from excessive client requests early, the Service Layer Rate Limiter enforces per-user limits within business logic, and the Database Layer Rate Limiter prevents database overload by limiting DB access rates. The Configuration Management Service centrally manages rate limit policies, pushing updates to all layers. This layered approach ensures robust, fine-grained control over request rates, improving system stability and fairness.

Primary Focus

✓

Practice

(1/5)
1. In the request flow, at step 3 the API Gateway forwards the request to the BFF layer. What happens at step 4 inside the BFF before calling downstream microservices?
easy
A. BFF aggregates and transforms data from multiple microservices into a client-specific response
B. BFF caches the entire response from microservices before returning to client
C. BFF directly proxies the request without modification to microservices
D. BFF performs authentication and then sends request to a single microservice

Solution

  1. Step 1: Understand BFF responsibilities at step 4

    At step 4, the BFF aggregates data from multiple microservices and transforms it into a response tailored to the client's needs.

  2. Step 2: Eliminate incorrect options

    BFF caches the entire response from microservices before returning to client is wrong because caching happens after response, not before calling microservices. BFF directly proxies the request without modification to microservices is incorrect as BFF modifies requests/responses rather than proxying blindly. BFF performs authentication and then sends request to a single microservice is incomplete; authentication usually happens earlier at API Gateway, and BFF calls multiple microservices, not just one.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    BFF aggregates and transforms data before responding [check]
Hint: BFF aggregates and transforms data before responding [check]
Common Mistakes:
2. For the For-You feed algorithm, which architecture best balances freshness of recommendations with scalability when serving millions of users?
medium
A. Use a monolithic service that recomputes recommendations synchronously on every user request
B. Use a client-side recommendation engine to reduce server load
C. Use an offline batch job to precompute recommendations periodically and serve from cache
D. Use a real-time streaming pipeline to update recommendations instantly per user action

Solution

  1. Step 1: Evaluate synchronous recomputation

    Monolithic synchronous (A) causes high latency and poor scalability.

  2. Step 2: Compare batch vs streaming

    Streaming (C) offers freshness but is complex and costly at scale; client-side (D) lacks data for quality recommendations.

  3. Step 3: Select batch precompute

    Batch jobs (B) balance freshness and scalability by precomputing and caching recommendations.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Batch precompute caches recommendations for scalable freshness [check]
Hint: Batch precompute balances freshness and scale best [OK]
Common Mistakes:
3. You need to implement a live news feed with many clients receiving frequent updates but no client-to-server messages. Which technology is best considering scalability and simplicity?
medium
A. Use WebSockets to maintain persistent connections for all clients to push updates.
B. Use Server-Sent Events to push unidirectional updates efficiently with automatic reconnection.
C. Use Long Polling to simulate server push by clients repeatedly requesting updates.
D. Use HTTP/2 server push to send updates without client requests.

Solution

  1. Step 1: Analyze communication pattern

    Live news feed requires unidirectional server-to-client updates with many clients and no client messages.

  2. Step 2: Evaluate technology trade-offs

    Server-Sent Events efficiently support unidirectional streaming with automatic reconnection and lower overhead than WebSockets. WebSockets add complexity and resource usage for no client-to-server messages. Long Polling is less efficient due to repeated HTTP requests. HTTP/2 server push is not widely supported for this use case.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Server-Sent Events optimize unidirectional streaming with scalability [check]
Hint: Unidirectional + many clients -> Server-Sent Events [check]
Common Mistakes:
4. For a system requiring extremely low false negatives and exact key existence checks at scale, which approach is best?
medium
A. Use a counting Bloom filter to track exact key counts and avoid backend queries
B. Use only a Bloom filter for all key existence checks to minimize latency
C. Use a distributed cache storing all keys for exact lookups without Bloom filters
D. Combine a Bloom filter for negative filtering with a backend exact lookup for positives

Solution

  1. Step 1: Analyze false negative tolerance

    Bloom filters have zero false negatives but allow false positives, so exact checks need backend confirmation.

  2. Step 2: Evaluate approaches

    Only Bloom filter (A) risks false positives causing incorrect hits. Distributed cache (C) is costly at scale. Counting Bloom filters (D) track counts but still have false positives and complexity.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Bloom filter filters negatives; backend confirms positives for exactness [check]
Hint: Bloom filter filters negatives; backend confirms positives [check]
Common Mistakes:
5. At 10x scale, which component in a Kafka-like distributed message queue is most likely to fail first, and why?
hard
A. The Kafka brokers, because partition leaders become overloaded with write and replication traffic
B. The consumer clients, because they cannot keep up with increased message consumption rates
C. The ZooKeeper ensemble, due to coordination overhead and leader election delays under heavy load
D. The network switches, due to increased packet loss under high throughput

Solution

  1. Step 1: Identify bottlenecks at 10x scale

    Network switches (A) scale with hardware upgrades; ZooKeeper (C) handles coordination but is lightweight compared to brokers; consumers (D) can be scaled horizontally.

  2. Step 2: Kafka broker partition leader overload

    Partition leaders handle all writes and replication for their partitions; at 10x scale, leaders become hotspots causing CPU, disk, and network saturation, leading to failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Partition leaders overloaded -> broker failure first at scale [check]
Hint: Partition leaders handle all writes -> overload first at scale [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