Bird
Raised Fist0

Distributed Rate Limiting - Redis-Based Centralized Counter Approach

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Load Balancer

Receives client HTTP request

Load Balancer accepts incoming request and selects API Server

Protocol:HTTP
BeforeClient request arrives at system entry point
AfterRequest forwarded to selected API Server
API Servers

Checks rate limit counter in Redis

API Server issues Redis INCR command to increment request count

Protocol:Redis INCR
BeforeAPI Server received request without current rate limit count
AfterCounter incremented atomically in Redis Cluster
Redis Cluster

Processes INCR command atomically

Redis increments centralized counter and returns new count

Protocol:Redis INCR
BeforeCounter value reflects previous request count
AfterCounter value updated with current request increment
Redis Replica

Receives replication update from Redis Cluster

Replica asynchronously replicates updated counter state

Protocol:Redis Replication
BeforeReplica has slightly stale counter value
AfterReplica counter updated to latest value
API Servers

Decides to allow or reject request based on counter

API Server compares counter to rate limit threshold

Protocol:Internal logic
BeforeAPI Server has latest counter value from Redis
AfterRequest allowed or rejected based on counter threshold
Monitoring & Alerting

Receives metrics from Redis Cluster

Metrics pushed periodically for rate limit usage monitoring

Protocol:Metrics Push
BeforeMonitoring has no recent metrics for counters
AfterMonitoring updated with current rate limit usage metrics
🏗️
Architecture Diagram
Architecture Diagram
          ┌───────────────────┐
          │   Load Balancer   │
          └─────────┬─────────┘
                    │ HTTP Request
                    ▼
          ┌───────────────────┐
          │    API Servers    │
          └───────┬───────────┘
                  │ Redis GET/INCR
                  ▼
          ┌───────────────────┐
          │   Redis Cluster   │
          │  (central ctr)    │
          └───────┬───────────┘
                  │ Replication
                  ▼
          ┌───────────────────┐
          │   Redis Replica   │
          └───────────────────┘
                  │ Metrics Push
                  ▼
          ┌────────────────────────┐
          │  Monit. & Alerting     │
          └────────────────────────┘
Design Rationale

This architecture implements distributed rate limiting using a centralized Redis Cluster that stores atomic counters per client. Incoming requests first hit the Load Balancer, which routes them to API Servers. The API Servers increment counters in Redis using atomic INCR commands to ensure consistency. Redis Replicas asynchronously replicate the counter state to scale read queries and provide failover. Monitoring & Alerting components receive metrics pushed from Redis to track usage and trigger alerts on breaches. This design balances strong consistency for rate limit enforcement with read scalability and observability.

Primary Focus

✓

Practice

(1/5)
1. If the durability mechanism (write-ahead log) is disabled in a transactional database, what exact failure occurs when the system crashes during a commit?
medium
A. The transaction partially commits, causing inconsistent database state
B. The database blocks all new transactions until recovery completes
C. The transaction appears committed to the client but is lost after crash, causing data loss
D. The transaction is rolled back automatically, preserving consistency

Solution

  1. Step 1: Role of write-ahead log (WAL)

    WAL ensures durability by recording changes before commit; without it, recovery cannot guarantee committed data.

  2. Step 2: Trace failure on crash without WAL

    Database must block new transactions and perform full recovery to avoid inconsistent state, causing availability loss.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    No WAL -> recovery blocks new transactions to maintain consistency [check]
Hint: No WAL means recovery blocks new transactions [check]
Common Mistakes:
2. For handling 10x traffic spikes in a flash sale, which architecture choice best balances consistency and availability under network partitions?
medium
A. Use an eventually consistent cache layer with asynchronous database writes
B. Use a distributed lock service to serialize all purchase requests
C. Use a single master database with read replicas for scaling reads
D. Use a strongly consistent distributed database with synchronous replication

Solution

  1. Step 1: Understand flash sale constraints

    Flash sales require high availability and low latency during spikes; strict consistency can cause blocking and failures.

  2. Step 2: Evaluate architectures

    Strong consistency with sync replication (A) causes high latency and availability loss under partitions. Single master (C) bottlenecks writes. Distributed locks (D) serialize requests, hurting throughput. Eventually consistent cache with async writes (B) allows high availability and scales under burst, tolerating slight delays.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Async writes + eventual consistency -> high availability under spikes [check]
Hint: Eventual consistency favors availability during spikes [check]
Common Mistakes:
3. If the token assignment metadata is lost or corrupted in a consistent hashing system with virtual nodes, what exactly breaks?
medium
A. Only new nodes fail to receive keys, existing nodes continue serving correctly
B. Requests cannot be routed to correct nodes, causing key lookups to fail or go to wrong nodes
C. The system continues routing keys correctly but load balancing is uneven
D. The system falls back to modulo hashing automatically without data loss

Solution

  1. Step 1: Understand role of token assignment metadata

    Token metadata maps virtual nodes to physical nodes; losing it breaks new node integration.

  2. Step 2: Trace failure impact

    Existing nodes continue serving keys assigned before loss; new nodes cannot be assigned tokens properly.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Token metadata loss blocks new node assignment; existing nodes unaffected [check]
Hint: Token metadata loss blocks new nodes, existing nodes serve [check]
Common Mistakes:
4. If the health check module fails to run, what is the exact failure observed in the load balancer's routing behavior?
medium
A. Load balancer reroutes traffic randomly ignoring server health
B. Load balancer blocks all traffic until health checks resume
C. Load balancer routes only to a cached subset of servers marked healthy previously
D. Load balancer continues routing to all servers, including unhealthy ones, causing client errors

Solution

  1. Step 1: Understand health check module role

    Health checks detect unhealthy servers; without them, no updates occur to remove bad servers.

  2. Step 2: Trace routing behavior without health checks

    Load balancer routes to all servers indiscriminately, including unhealthy ones, causing client errors.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No health checks -> no removal of unhealthy servers -> client errors [check]
Hint: No health checks means no unhealthy server removal [check]
Common Mistakes:
5. You need to design a distributed configuration system that supports dynamic updates with strong consistency guarantees. Which approach is best suited for this scenario?
medium
A. Use Zookeeper to store configuration with watches for immediate update notifications
B. Use a distributed cache with eventual consistency and periodic refresh
C. Use a relational database with polling clients for configuration changes
D. Use a message queue to broadcast configuration changes asynchronously

Solution

  1. Step 1: Identify consistency and update requirements

    Strong consistency and immediate update notification are required.

  2. Step 2: Evaluate options

    Distributed cache with eventual consistency delays updates; relational DB polling adds latency; message queue is asynchronous without state storage.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Zookeeper watches -> immediate, consistent config updates [check]
Hint: Watches + strong consistency -> Zookeeper for config updates [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