Bird
Raised Fist0

Design a Real-Time Leaderboard - Sorted Sets, Redis, Ranking at Scale

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design a Real-Time Leaderboard - Sorted Sets, Redis, Ranking at Scale
Real-time ranking with Redis Sorted Sets for sub-second leaderboard updates at 2B DAU scale
hardFinancial and Real-Time SystemsFreq: high
Prerequisites:Caching BasicsKey-Value StoresDistributed Systems FundamentalsData Modeling for NoSQL
⚙️
Functional Requirements
  • Support real-time score updates for users with sub-second latency
  • Provide top-N leaderboard queries with sorted user rankings
  • Allow querying individual user rank and score efficiently
  • Support multiple leaderboards (e.g., daily, weekly, all-time)
  • Handle concurrent updates and queries without data inconsistency
  • Expire or archive old leaderboard data after retention period
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU)
  • Handle peak write QPS of approximately 1 million writes/sec
  • Provide 100ms P99 latency for leaderboard read queries
  • Ensure 99.99% system availability
  • Data retention of leaderboard data for 30 days with automatic expiry
❓
Clarifying Questions to Ask
  • What is the expected number of leaderboard updates per user per day?
  • What is the maximum size of the leaderboard (top-N) to be supported?
  • Are leaderboard scores only increasing or can they decrease?
  • Is eventual consistency acceptable for leaderboard reads or is strong consistency required?
  • What is the retention period for leaderboard data?
  • Are there multiple types of leaderboards (e.g., global, regional, friends)?
Out of Scope
✗ User authentication and authorization
✗ Monetization or payment processing related to leaderboard
✗ Complex analytics or machine learning on leaderboard data
✗ Cross-region multi-datacenter replication
📌
Assumptions
  • 2 billion DAU
  • 40 score updates per user per day
  • 100 bytes per update message
  • Leaderboard top-N queries constitute 10% of total read traffic
⚡
QPS Calculation
write qps2B users × 40 updates/day ÷ 86400 sec ≈ 925,926 writes/sec
peak write qpsAssuming 2× peak factor → 1,851,852 writes/sec
read qpsAssuming 1 read per 10 writes → 92,593 reads/sec
peak read qpsAssuming 2× peak factor → 185,185 reads/sec
💾
Storage Estimate
daily storage2B × 40 × 100 bytes = 8 TB/day
retention days30
total storage8 TB × 30 = 240 TB
with replicationAssuming 3× replication → 720 TB total
🖥️
Server Estimate
redis cluster nodesAssuming 50 GB RAM per Redis node → 720 TB ÷ 50 GB ≈ 14,400 nodes
api serversAssuming 1000 RPS per API server → 185,185 peak read RPS ÷ 1000 ≈ 186 servers
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |  Client Apps   |
          +-------+--------+
                  |
          +-------v--------+
          |  API Gateway   |
          +-------+--------+
                  |
          +-------v--------+
          |  Write Service |
          +-------+--------+
                  |
          +-------v--------+
          | Kafka Cluster  |
          +-------+--------+
                  |
          +-------v--------+
          | Redis Cluster  |
          | (Sorted Sets)  |
          +-------+--------+
                  |
          +-------v--------+
          | Read Service   |
          +-------+--------+
                  |
          +-------v--------+
          | Client Apps    |
🧩
Components
API Gateway
Entry point for client requests, routes to write or read services
Why thisNginx or Envoy provides high throughput, low latency routing with TLS termination
Why notDirect client connection to backend risks overload and lacks centralized control
Write Service
Validates and publishes score update events to Kafka
Why thisStateless microservice scales horizontally and decouples ingestion from processing
Why notDirect writes to Redis cause hot keys and overload Redis cluster
Kafka Cluster
Durable, ordered, partitioned event queue for score updates
Why thisKafka supports high throughput (millions of messages/sec) with partitioning for parallelism
Why notRabbitMQ lacks Kafka’s throughput and partitioning scalability at this scale
Redis Cluster (Sorted Sets)
Stores leaderboard data with sorted sets for O(log N) insertion and rank queries
Why thisRedis Sorted Sets natively support score-based ranking with sub-millisecond latency and TTL expiry
Why notCassandra or DynamoDB lack efficient sorted set operations and have higher read latency
Read Service
Serves leaderboard queries (top-N, user rank) by querying Redis cluster
Why thisStateless service horizontally scales to meet 100ms P99 latency SLA for reads
Why notDirect client queries to Redis expose Redis to unpredictable load and security risks
🔄
Data Flow
1
Client Apps → API Gateway
Send score update or leaderboard query request
API Gateway routes requests to appropriate service
2
API Gateway → Write Service
Forward score update requests
Write Service validates and publishes events to Kafka
3
Write Service → Kafka Cluster
Publish score update event
Kafka partitions events by leaderboard ID for parallel processing
4
Kafka Cluster → Redis Cluster
Consume events and update Redis Sorted Sets
Redis Sorted Sets update user scores and ranks atomically
5
Client Apps → API Gateway
Send leaderboard read queries
API Gateway routes to Read Service
6
API Gateway → Read Service
Forward leaderboard queries
Read Service queries Redis Sorted Sets for top-N or user rank
7
Read Service → Redis Cluster
Fetch sorted set data
Redis returns rank and score with sub-millisecond latency
8
Read Service → Client Apps
Return leaderboard results
Results delivered within 100ms P99 latency SLA
🗄️
leaderboard_scores
PK: leaderboard_id
leaderboard_id (string)user_id (string)score (double)timestamp (timestamp)
Stores user scores per leaderboard sorted by score descending and user_id ascending
🗄️
user_leaderboard_rank
PK: user_id
user_id (string)leaderboard_id (string)rank (int)score (double)last_updated (timestamp)
Stores user rank and score per leaderboard for quick lookup
🔌
POST
UpdateScore
Request
{
  "user_id": "string",
  "leaderboard_id": "string",
  "score": "double"
}
Response
{
  "status": "string",
  "message": "string"
}
Updates the user's score in the specified leaderboard
🔌
GET
GetTopN
Request
{
  "leaderboard_id": "string",
  "N": "int"
}
Response
{
  "entries": [
    {
      "user_id": "string",
      "score": "double",
      "rank": "int"
    }
  ]
}
Retrieves top N users from the specified leaderboard
🔌
GET
GetUserRank
Request
{
  "user_id": "string",
  "leaderboard_id": "string"
}
Response
{
  "rank": "int",
  "score": "double"
}
Retrieves the rank and score of a user in a specified leaderboard

Practice

(1/5)
1. A web application needs to ensure that cache entries are updated immediately after every write to the database to prevent stale reads. Which caching pattern best fits this requirement?
easy
A. Cache Aside, where the application updates the cache only on cache misses
B. Write-Through, where writes go through the cache and update the database synchronously
C. Read-Through, where the cache loads data on reads but writes bypass the cache
D. Write-Behind, where writes are buffered and asynchronously flushed to the database

Solution

  1. Step 1: Identify cache update timing

    Write-Through updates cache and database synchronously, ensuring cache is always fresh.

  2. Step 2: Eliminate other patterns

    Cache Aside updates cache only on misses, risking stale cache after writes; Read-Through only loads on reads; Write-Behind delays DB update, risking stale cache.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Write-Through synchronously updates cache and DB [check]
Hint: Write-Through syncs cache and DB on writes [check]
Common Mistakes:
2. A distributed system needs to generate unique IDs for millions of events per second without coordination delays. Which component is best suited to generate these IDs efficiently?
easy
A. A decentralized ID generator using timestamp and node ID bits (e.g., Snowflake)
B. A centralized relational database with auto-increment primary keys
C. A UUID v4 generator relying on random number generation
D. A distributed cache like Redis with INCR commands for ID generation

Solution

  1. Step 1: Identify coordination bottlenecks in centralized DB

    Auto-increment keys require coordination, causing latency and contention at high scale.

  2. Step 2: Evaluate decentralized timestamp-based ID generators

    Snowflake-style IDs combine timestamp and node ID, enabling scalable, ordered unique IDs without coordination.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Decentralized timestamp + node ID -> scalable unique ID generation [check]
Hint: Decentralized timestamp + node ID avoids coordination delays [check]
Common Mistakes:
3. If the recursive DNS server's cache is completely disabled, what is the most immediate failure mode experienced by users during domain resolution?
medium
A. Users' browsers fallback to using IP addresses directly, bypassing DNS
B. Users receive stale IP addresses causing connection failures
C. The recursive server returns IP addresses from its local hosts file instead of querying DNS servers
D. The recursive server blocks user queries until authoritative servers respond, increasing latency and potential timeouts

Solution

  1. Step 1: Understand recursive server caching role

    The recursive DNS server cache reduces query latency by storing recent results. Without caching, every query requires a full resolution chain traversal.

  2. Step 2: Trace failure impact

    Without cache, recursive server must synchronously query authoritative servers for every request, causing increased latency and possible timeouts, blocking user queries.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No cache -> synchronous queries -> high latency and blocking [check]
Hint: No cache means blocking queries until authoritative response [check]
Common Mistakes:
4. For a global typeahead autocomplete service that must support fuzzy matching and ranking by popularity, which architecture is best suited?
medium
A. Use Elasticsearch with fuzzy queries and custom scoring to handle ranking and typo tolerance
B. Use a prefix hash map with precomputed fuzzy variants for each prefix
C. Use an in-memory Trie for all prefixes with fuzzy matching logic implemented on top
D. Use a relational database with LIKE queries and additional application-side ranking

Solution

  1. Step 1: Evaluate fuzzy matching and ranking requirements

    Fuzzy matching and popularity ranking require complex scoring and typo tolerance, which Elasticsearch supports natively with fuzzy queries and custom scoring functions.

  2. Step 2: Assess other options

    Trie and prefix hash map lack built-in fuzzy matching and ranking; relational DB LIKE queries are inefficient and don't scale well for fuzzy search.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Elasticsearch supports fuzzy search and ranking out-of-the-box [check]
Hint: Elasticsearch = fuzzy + ranking built-in [check]
Common Mistakes:
5. At 10x scale, which component is most likely to fail first and why in Slack's real-time delivery system?
hard
A. Chat servers, because WebSocket connections are stateful and cannot be resharded easily
B. Presence service, because TTL cache invalidations overwhelm the system
C. Kafka brokers, because partition count cannot scale beyond a fixed limit
D. The database, because increased writes cause locking and slow queries

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    Chat servers hold WebSocket connections in memory, which are stateful and tied to specific servers, limiting horizontal scaling.

  2. Step 2: Compare other components

    Databases can be sharded; Kafka scales with partitions; presence service caches can be distributed; chat servers' stateful connections are the hardest to shard.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful WebSocket connections -> chat servers bottleneck at 10x scale [check]
Hint: Stateful WebSocket binds chat servers -> first bottleneck [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