Bird
Raised Fist0

Design an API Rate Limiter - Algorithms, Distributed Counter, Edge Enforcement

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Clients

Send API request

Client sends HTTPS request to Edge Node

Protocol:HTTPS
BeforeClient has prepared API request to send
AfterRequest is in transit to Edge Node
Edge Nodes

Fetch rate limit config

Edge Node queries Config Service for current limits

Protocol:HTTP REST
BeforeEdge Node received API request but lacks config
AfterEdge Node has current rate limit config cached
Edge Nodes

Check and increment counter

Edge Node issues Redis INCR and GET to check usage

Protocol:Redis INCR/GET
BeforeEdge Node has config but no usage count for client
AfterCounter incremented; usage count retrieved
Distributed Redis Cluster

Update distributed counter

Redis increments counter atomically for client key

Protocol:Redis INCR
BeforeCounter value is previous usage count
AfterCounter value updated with new usage count
Edge Nodes

Allow or reject request

Edge Node compares count to limit and decides

Protocol:Internal logic
BeforeEdge Node has usage count and limit
AfterRequest allowed or rejected based on limit
Metrics & Monitoring

Record rate limit event

Edge Node publishes metrics about request outcome

Protocol:Metrics API
BeforeRequest outcome decided but not recorded
AfterMetrics system has updated counters for monitoring
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Clients  │
└───────┬───────┘
        │ HTTPS Req
        ▼
┌───────────────┐
│  Edge Nodes   │
│ (Rate Limiter)│
└───────┬───────┘
        │ Redis INCR/GET
        ▼
┌─────────────────────────┐
│ Distributed Redis Cluster│
│  (Dist Counters)        │
└───────┬───────────┬─────┘
        │ Redis GET  │ Redis PUB
        ▼           ▼
┌───────────────┐  ┌───────────────┐
│ Config Service│  │Metrics &      │
│ (Rate Limits) │  │Monitoring     │
└───────────────┘  └───────────────┘
Design Rationale

This architecture shows an API request flowing from API Clients to Edge Nodes, which enforce rate limits using distributed counters stored in a Redis cluster. Edge Nodes first fetch rate limit configurations from the Config Service to apply the correct limits. They then increment and check counters atomically in Redis to track usage per client. Based on the counter value and configured limits, the Edge Node allows or rejects the request immediately at the edge, minimizing latency. Metrics & Monitoring collects data on rate limiting events for operational visibility. This design balances low latency enforcement with strong consistency of distributed counters, leveraging Redis for atomic increments and Config Service for dynamic limit updates.

Primary Focus

✓

Practice

(1/5)
1. In a file storage system, at step 3 the client requests a file write. What happens inside the metadata server at this step?
easy
A. The metadata server sends the file data to object storage for persistence.
B. The metadata server writes the file data blocks directly to disk.
C. The metadata server updates the file's inode and directory entries to reflect the new write.
D. The metadata server caches the entire file in memory without updating disk metadata.

Solution

  1. Step 1: Understand metadata server role in file write

    The metadata server manages file metadata like inodes and directory entries, not the actual data blocks.

  2. Step 2: Trace what happens at step 3

    On a write request, the metadata server updates the inode and directory metadata to reflect changes; data blocks are handled separately by storage nodes.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Metadata server updates inode, not data blocks [check]
Hint: Metadata server updates metadata, not file data blocks [check]
Common Mistakes:
2. In the deployment system request flow, at Step 4 the Canary Controller evaluates metrics from the new version. What happens if error rates exceed the threshold at this step?
easy
A. Canary Controller immediately promotes the new version to 100% traffic
B. Canary Controller triggers automatic rollback to previous stable version
C. Canary Controller ignores errors and continues increasing traffic
D. Canary Controller disables feature flags for the new version

Solution

  1. Step 1: Understand Step 4 role

    At Step 4, Canary Controller monitors metrics to decide if rollout continues or aborts.

  2. Step 2: Analyze error threshold breach

    If error rates exceed threshold, rollback is triggered to prevent faulty version promotion.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Canary Controller triggers rollback on error threshold breach [check]
Hint: Canary aborts rollout and rolls back on high error rates [OK]
Common Mistakes:
3. In the request flow for creating a pull request, at step 5 the Merge Worker attempts to apply the patch to the target branch. What happens if a merge conflict is detected at this step?
easy
A. The Merge Worker marks the pull request as conflicted and notifies the user to resolve manually
B. The Merge Worker retries the merge indefinitely until no conflicts remain
C. The Merge Worker discards the pull request and deletes the source branch
D. The Merge Worker automatically resolves conflicts using the latest commit's changes

Solution

  1. Step 1: Trace Merge Worker behavior at Step 5

    When a merge conflict occurs, automatic resolution is unsafe; the system flags the PR as conflicted and requires manual user intervention.

  2. Step 2: Eliminate incorrect options

    Automatic conflict resolution risks data loss; discarding PR or deleting branches is destructive; infinite retries cause resource exhaustion.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Merge conflicts -> PR marked conflicted, user notified [check]
Hint: Conflicts block merge until user resolves [check]
Common Mistakes:
4. A microservice needs to discover and connect to other services dynamically without a central registry bottleneck. Which component best handles this requirement?
easy
A. Static configuration files listing all service endpoints
B. A centralized service registry with server-side load balancing
C. DNS-based service discovery without client-side caching
D. Client-side service discovery with local caching and load balancing

Solution

  1. Step 1: Identify client-side discovery benefits

    Client-side discovery allows services to query a registry and cache endpoints locally, avoiding central bottlenecks and enabling dynamic load balancing.

  2. Step 2: Eliminate other options

    A centralized service registry with server-side load balancing centralizes load balancing, risking bottlenecks; DNS-based service discovery without client-side caching lacks caching, causing latency; Static configuration files listing all service endpoints is static and not dynamic.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Client caches endpoints and load balances locally [check]
Hint: Client caches endpoints locally for dynamic load balancing [OK]
Common Mistakes:
5. If the Kafka cluster used for fan-out events crashes and loses the latest messages, what exactly breaks in the newsfeed delivery?
medium
A. The system falls back to synchronous push, increasing write latency
B. Posts published just before the crash are lost; followers never see them
C. Followers receive duplicate posts due to re-delivery attempts
D. Delivery Workers block indefinitely waiting for missing messages

Solution

  1. Step 1: Understand Kafka's role in fan-out

    Kafka buffers fan-out events; Delivery Workers consume from Kafka to deliver posts asynchronously.

  2. Step 2: Trace failure impact

    If Kafka crashes and loses messages, Delivery Workers waiting on those messages block or stall, causing delivery delays.

  3. Step 3: Eliminate other options

    Duplicates (A) occur with retries, not loss. Lost posts (B) happen but are not the immediate failure mode. Fallback to synchronous push (D) is not automatic.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Kafka crash causes Delivery Workers to block waiting for lost messages [check]
Hint: Kafka crash blocks Delivery Workers waiting for messages [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