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
45 min · senior
senior

You are building a real-time leaderboard system for a gaming startup with 50 million daily active users (DAU). The leaderboard must update player rankings instantly as scores arrive, support global and segmented leaderboards, and serve queries with P99 latency under 200ms. The system must encrypt sensitive user data at rest and in transit, handle up to 1 million score updates per second, and support offline delivery of leaderboard snapshots to clients when they reconnect.

Constraints
  • P99 query latency under 200ms at peak load
  • End-to-end encryption of user data in transit and at rest
  • Support 1 million score updates per second
  • Offline delivery of leaderboard snapshots for reconnecting clients
  • Global and segmented leaderboards with dynamic filters
📋
Guided Steps
1/5
Step 1
Choosing the Data Store for Real-Time Ranking
Which data store technology will you use to maintain the leaderboard rankings with low latency and why?
💡 Hint
Consider a data structure that supports sorted order with efficient score updates and rank queries.
Key Decision
Use Redis Sorted Sets (ZSET) because they provide O(log N) insertion and rank retrieval, support atomic score updates, and have built-in commands like ZADD and ZRANK optimized for leaderboard use cases.
Interviewer Expectation
Mid-level: Names Redis Sorted Sets for leaderboard. Senior: Explains O(log N) complexity, atomicity of ZADD, and why alternatives like MongoDB or Cassandra sorted queries are too slow or complex at 1M updates/sec.
⚠️Common Wrong Answer
Using a relational database with ORDER BY queries - leads to high latency and poor write throughput at 1 million updates per second.
Step 2
Handling Scale and Partitioning
How will you scale Redis to handle 1 million score updates per second and support global plus segmented leaderboards?
💡 Hint
Think about sharding strategies and how to partition data to avoid hot keys and bottlenecks.
Key Decision
Use Redis Cluster with sharding by leaderboard type and player ID hash to distribute load evenly. For segmented leaderboards, maintain separate sorted sets per segment to isolate traffic and enable parallel queries.
Interviewer Expectation
Mid-level: Mentions Redis Cluster for sharding. Senior: Explains shard key choice, how to avoid hot partitions by hashing player IDs, and trade-offs of segmenting leaderboards into multiple sorted sets versus filtering at query time.
⚠️Common Wrong Answer
Single Redis instance or naive sharding by player ID only - causes hot keys and single-node bottlenecks, breaking under 1M updates/sec.
Step 3
Ensuring Data Security and Encryption
How will you ensure encryption of sensitive user data both at rest and in transit in this leaderboard system?
💡 Hint
Consider encryption layers at network and storage levels, and how Redis supports encryption.
Key Decision
Enable TLS for all Redis client-server communication to encrypt data in transit. Use Redis Enterprise or self-managed Redis with disk encryption (e.g., LUKS) for at-rest encryption. Encrypt sensitive fields before storing in Redis if needed for end-to-end encryption.
Interviewer Expectation
Mid-level: Mentions TLS for in-transit encryption. Senior: Details Redis Enterprise TLS support, disk encryption options, and client-side encryption trade-offs for compliance and zero-trust environments.
⚠️Common Wrong Answer
No encryption or relying only on network-level VPN - exposes data to insider threats and does not meet compliance.
Step 4
Designing Offline Delivery and Snapshot Sync
How will clients who were offline sync leaderboard updates efficiently when they reconnect?
💡 Hint
Think about snapshotting, incremental updates, and how to track client state for delta delivery.
Key Decision
Implement a snapshot service that periodically exports leaderboard state to a durable store like Amazon S3. Use Redis Streams to capture incremental score updates with consumer groups for offline clients to replay missed events and catch up.
Interviewer Expectation
Mid-level: Suggests periodic snapshots. Senior: Explains combining Redis Streams for incremental updates with snapshot fallback, how consumer groups track client offsets, and trade-offs of snapshot frequency versus stream retention.
⚠️Common Wrong Answer
Clients always reload full leaderboard on reconnect - causes high bandwidth and latency spikes, poor user experience.
Step 5
API Design for Core Leaderboard Operations
Sketch three core API endpoints for score submission, leaderboard retrieval, and offline sync. What are their inputs, outputs, and key considerations?
💡 Hint
Consider atomicity for score submission, pagination for retrieval, and state tracking for sync.
Key Decision
POST /submitScore(playerId, leaderboardId, score): atomically updates Redis ZSET with ZADD. GET /leaderboard(leaderboardId, topN, offset): returns sorted players with ranks using ZRANGE with scores. GET /syncUpdates(playerId, lastSeenStreamId): returns Redis Stream entries since lastSeenStreamId for incremental sync.
Interviewer Expectation
Mid-level: Names endpoints and basic parameters. Senior: Details atomic Redis commands, pagination strategies, stream offset management, and error handling for consistency.
⚠️Common Wrong Answer
Single GET endpoint returning full leaderboard always - leads to large payloads and high latency.
🔌
API Design Challenge
Sketch 3 core API endpoints for the leaderboard system that cover score submission, leaderboard retrieval, and offline snapshot sync.
Hints
  • How does the client submit a new score and ensure it updates the leaderboard atomically?
  • How does the client retrieve the top N players or a player's rank efficiently?
  • How does the client sync missed leaderboard updates after being offline?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use Redis Sorted Sets for leaderboard data structure to meet latency and update scale
  • Shard Redis using Redis Cluster with appropriate partition keys to handle 1M updates/sec
  • Implement TLS and disk encryption to secure data in transit and at rest
  • Design offline sync using Redis Streams and snapshots for efficient client catch-up
  • Define clear API endpoints with atomic score submission and paginated leaderboard retrieval
Good to Have - 30%
  • Explain trade-offs of segmenting leaderboards vs filtering at query time
  • Discuss snapshot frequency and retention policies for Redis Streams
  • Consider client-side encryption for end-to-end data protection
  • Detail error handling and consistency guarantees in API design
Bonus - 10%
  • Propose monitoring and alerting strategies
Anti-patterns to Avoid
✅
Model Answer
▼ Reveal

This design uses Redis Sorted Sets (ZSET) for real-time leaderboard ranking, leveraging Redis Cluster for sharding to handle 1 million updates per second. Data security is ensured via TLS for in-transit encryption and disk encryption for at-rest data. Offline clients sync via Redis Streams with consumer groups and periodic snapshots stored in durable storage like Amazon S3. The API includes atomic score submission, paginated leaderboard retrieval, and incremental update sync endpoints.

Key Decisions
  • Use Redis Sorted Sets (ZSET) for O(log N) score updates and rank queries with atomic ZADD commands
  • Shard Redis Cluster by leaderboard type and player ID hash to distribute load and avoid hot keys
  • Enable TLS for all Redis client-server communication and use disk encryption (e.g., LUKS) for at-rest data
  • Implement Redis Streams with consumer groups to track offline clients and deliver incremental updates
  • Periodically snapshot leaderboard state to durable storage (Amazon S3) for recovery and offline sync fallback
  • Design APIs with atomic score submission (POST /submitScore), paginated leaderboard retrieval (GET /leaderboard), and stream-based incremental sync (GET /syncUpdates)
  • Redis Sorted Sets (ZSET) for efficient O(log N) score updates and rank queries
  • Redis Cluster sharding by leaderboard type and player ID hash to scale 1M updates/sec
  • TLS encryption for Redis client-server communication and disk encryption for at-rest data
  • Redis Streams with consumer groups for incremental offline update delivery
  • Periodic leaderboard snapshots exported to durable storage (e.g., Amazon S3) for recovery
  • API design with atomic ZADD for score submission, paginated ZRANGE for retrieval, and stream-based sync
  • Segmented leaderboards implemented as separate Redis Sorted Sets to isolate traffic and queries
  • Client-side tracking of last seen stream IDs to enable efficient delta sync on reconnect

Practice

(1/5)
1. A system must handle 1 million events per second, ensuring durability and ordered processing per aggregate. Which component best fits this requirement?
easy
A. Use a Redis pub/sub channel for event distribution
B. Use Kafka with partitioning by aggregate ID
C. Use a relational database with triggers for event handling
D. Use RabbitMQ with round-robin queue distribution

Solution

  1. Step 1: Identify Kafka's role in event sourcing

    Kafka supports high throughput with partitioning by aggregate ID, ensuring ordered event processing per aggregate.

  2. Step 2: Evaluate other options

    Redis pub/sub lacks durability guarantees; relational DB triggers don't scale to 1M events/sec; RabbitMQ's round-robin breaks ordering per aggregate.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka partitions by aggregate ID -> ordered, durable event stream [check]
Hint: Kafka partitions preserve order per aggregate [check]
Common Mistakes:
2. For a mobile client calling a flaky backend service, which approach best balances responsiveness and failure isolation?
medium
A. Use synchronous calls with retries and exponential backoff
B. Rely on client-side caching to avoid backend calls during failures
C. Implement a circuit breaker with a short timeout and fallback response
D. Use a message queue to buffer requests and process asynchronously

Solution

  1. Step 1: Evaluate synchronous retries (A)

    Retries increase latency and risk cascading failures, bad for mobile responsiveness.

  2. Step 2: Compare asynchronous queue (C) and caching (D)

    Queues add delay and complexity; caching avoids calls but may serve stale data, not ideal for dynamic data.

  3. Step 3: Circuit breaker with short timeout and fallback (B)

    Provides quick failure detection, prevents cascading failures, and returns fallback to maintain responsiveness.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Circuit breaker with fallback balances isolation and responsiveness [check]
Hint: Circuit breaker with fallback keeps mobile responsive and isolated [OK]
Common Mistakes:
3. In a system using Kafka for write-ahead logging to ensure strong consistency, what exactly breaks if Kafka becomes unavailable during a write operation?
medium
A. The system falls back to eventual consistency, causing stale reads temporarily
B. The client's write blocks indefinitely until Kafka recovers, preventing data loss
C. The write is accepted locally but lost permanently if the server crashes before Kafka recovers
D. The system switches to causal consistency mode automatically to maintain availability

Solution

  1. Step 1: Trace failure impact on write path

    Without Kafka, writes accepted locally but not durably logged can be lost if the server crashes before Kafka recovers.

  2. Step 2: Eliminate other options

    The system falls back to eventual consistency, causing stale reads temporarily is incorrect because fallback to eventual consistency is not automatic; The client's write blocks indefinitely until Kafka recovers, preventing data loss is wrong because writes may not block indefinitely; The system switches to causal consistency mode automatically to maintain availability is false as consistency mode does not switch automatically.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Writes accepted locally but lost if server crashes before Kafka recovers [check]
Hint: Without Kafka, local writes risk loss if server crashes [check]
Common Mistakes:
4. If the Kafka cluster used for buffering document update events becomes unavailable, what is the immediate failure mode in the full-text search indexing pipeline?
medium
A. The system automatically switches to a backup message queue with identical ordering guarantees
B. Document update ingestion blocks, causing the entire indexing pipeline to stall and new updates to be lost if not retried
C. The indexing workers continue processing stale events from local cache, causing outdated search results
D. The inverted index becomes corrupted due to missing update events

Solution

  1. Step 1: Understand Kafka unavailability impact

    Without Kafka, ingestion of new document updates cannot proceed, causing blocking or stalling.

  2. Step 2: Evaluate options

    Indexing workers do not have local caches of events (A) and cannot continue processing. Automatic failover to a backup queue with identical ordering (C) is a designed mitigation. Index corruption (D) does not happen immediately; missing events cause stale results but not corruption.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Failover to backup queue prevents pipeline stall [check]
Hint: Kafka outage stalls ingestion unless backup queue with ordering [check]
Common Mistakes:
5. If the system loses the HyperLogLog register state due to a crash before merging sketches, what exactly breaks in the cardinality estimation process?
medium
A. The system will continue to provide exact counts from raw user IDs stored elsewhere
B. The system will undercount unique users because lost registers cause missing data in the union
C. The system will overcount unique users because duplicates are counted multiple times
D. The system will fail to detect new users but still count old users correctly

Solution

  1. Step 1: Understand HyperLogLog state loss impact

    Losing the register state means the approximate count for that shard is lost; no exact user IDs are stored elsewhere.

  2. Step 2: Check consequences on cardinality

    Without the register, the system cannot include that shard's data, causing undercounting, not overcounting or exact counts.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Lost registers -> missing data -> undercounting unique users [check]
Hint: Lost registers cause undercount, no exact backup [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