Bird
Raised Fist0

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

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

Receives new score submission from user

User sends score update via WebSocket

Protocol:WebSocket
BeforeUser has score ready to submit on client device
AfterAPI Gateway has received score and forwards to Write Service
Write Service

Publishes score update to Kafka topic

Write Service serializes and produces message to Kafka

Protocol:Kafka Produce
BeforeWrite Service has score data from API Gateway
AfterScore update is durably stored in Kafka topic
Kafka Cluster

Queues score update for consumption

Kafka stores message partitioned by user ID

Protocol:Kafka Consume
BeforeKafka topic contains new score message
AfterWrite Service consumer reads message for processing
Redis Cluster (Sorted Sets)

Updates sorted set with new score

Consumer updates user's score in Redis sorted set

Protocol:Redis GET/UPDATE
BeforeRedis sorted set has previous scores
AfterRedis sorted set reflects updated score and rank
Read Service

Reads updated leaderboard from Redis

Read Service queries Redis sorted set for top ranks

Protocol:Redis GET
BeforeRedis sorted set contains updated scores
AfterRead Service returns fresh leaderboard to clients
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────┐
│ Write Service │
└───────┬───────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│ Kafka Cluster │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌────────────────────────┐
│ Redis Cluster           │
│ (Sorted Sets for ranks)│
└───────┬────────────────┘
        │ Redis GET/UPDATE
        ▼
┌───────────────┐
│ Read Service  │
└───────────────┘
Design Rationale

This architecture uses an API Gateway to receive user score submissions over WebSocket, forwarding them to a Write Service. The Write Service publishes these updates to a Kafka Cluster, ensuring durable and scalable message queuing. A consumer reads from Kafka and updates the Redis Cluster's sorted sets, which maintain the leaderboard rankings efficiently. The Read Service queries Redis to serve real-time leaderboard data to clients. This design decouples writes and reads, leverages Kafka for scalability and durability, and uses Redis sorted sets for fast rank queries, enabling real-time leaderboard updates at scale.

Primary Focus

✓

Practice

(1/5)
1. A financial application requires that a transaction always leaves the database in a valid state according to business rules after commit. Which component primarily enforces this property?
easy
A. Consistency checks enforcing schema constraints after commit
B. Isolation level settings preventing dirty reads
C. Durability guarantees via write-ahead logging
D. Atomic commit protocol ensuring all-or-nothing transaction completion

Solution

  1. Step 1: Identify Consistency role

    Consistency ensures database state adheres to all defined rules and constraints after transaction commits.

  2. Step 2: Differentiate from other ACID properties

    Atomicity ensures all-or-nothing commit, Isolation controls concurrent access, Durability ensures persistence, but only Consistency enforces business rules.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Consistency enforces schema and business rules post-commit [check]
Hint: Consistency enforces valid state after commit [check]
Common Mistakes:
2. For a large-scale web crawler, which architecture best balances crawl rate and politeness when crawling millions of domains with varying rate limits?
medium
A. Centralized Scheduler with a global queue and a single Politeness Policy enforcer
B. Distributed Scheduler with domain-based sharding and local Politeness Policy enforcement per shard
C. Multiple independent crawlers each with their own Scheduler and no shared Politeness Policy
D. Single-threaded crawler with a priority queue sorted by domain crawl time

Solution

  1. Step 1: Analyze centralized vs distributed scheduling

    Centralized Scheduler becomes a bottleneck at scale; distributed sharding allows parallelism and localized politeness enforcement.

  2. Step 2: Evaluate other options

    Independent crawlers without shared politeness risk domain overload; single-threaded crawler can't scale to millions of domains.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Distributed sharding enables scalable politeness enforcement [check]
Hint: Distributed sharding scales politeness enforcement best [OK]
Common Mistakes:
3. If the health monitoring component of the GSLB fails silently, what is the most likely failure observed by end users?
medium
A. Users are routed to unhealthy data centers causing request failures or timeouts
B. Traffic is evenly distributed regardless of data center health, causing overload
C. DNS queries fail to resolve, causing complete service outage
D. Users experience increased latency due to rerouting through backup data centers

Solution

  1. Step 1: Understand health monitor role

    The health monitor informs GSLB which data centers are healthy; without it, GSLB cannot avoid unhealthy endpoints.

  2. Step 2: Analyze failure impact

    Without health info, GSLB routes users to unhealthy data centers causing failures (Users are routed to unhealthy data centers causing request failures or timeouts). Increased latency (Users experience increased latency due to rerouting through backup data centers) or DNS failures (DNS queries fail to resolve, causing complete service outage) are indirect or unlikely. Even traffic distribution (Traffic is evenly distributed regardless of data center health, causing overload) ignores health but is less precise than routing to unhealthy nodes.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Silent health monitor failure -> routing to unhealthy data centers [check]
Hint: No health data -> users sent to unhealthy data centers [check]
Common Mistakes:
4. Without a durable message queue like Kafka, what exactly breaks in a chat system's message delivery?
medium
A. The system fails to authenticate users leading to unauthorized access
B. Messages are encrypted incorrectly causing security breaches
C. Messages are duplicated multiple times due to lack of deduplication
D. Alice's send blocks until Bob responds; if Bob's server crashes, message is lost with no retry

Solution

  1. Step 1: Identify role of durable queue

    Kafka decouples sender and receiver; without it, sender waits synchronously for receiver's ack.

  2. Step 2: Trace failure without Kafka

    If Bob's server crashes, no ack arrives, send blocks indefinitely and message is lost with no retry mechanism.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No Kafka -> synchronous send blocks, message lost if receiver crashes [check]
Hint: No Kafka -> send blocks and message lost if receiver crashes [check]
Common Mistakes:
5. Without the Global Traffic Manager component in a multi-CDN setup, what is the most likely failure scenario when one CDN provider becomes unavailable?
medium
A. Origin server detects CDN failure and redirects traffic to healthy CDNs
B. Clients continue sending requests to the failed CDN, causing increased latency and errors
C. User requests automatically failover to the next CDN without delay
D. Edge caches replicate content from other CDNs to cover the outage

Solution

  1. Step 1: Understand role of Global Traffic Manager in failover

    It dynamically routes traffic away from failed CDNs. Without it, failover must be handled elsewhere.

  2. Step 2: Trace failure without Global Traffic Manager

    Origin server may attempt to redirect traffic, but this adds latency and is less dynamic than traffic manager.

  3. Step 3: Eliminate other options

    Automatic client failover (A) requires client intelligence not assumed here. Clients sending to failed CDN (B) is possible but less likely if origin redirects. Edge caches (D) do not replicate across CDNs automatically.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Without traffic manager, origin server redirects traffic causing latency and partial failover [check]
Hint: No traffic manager -> origin server handles failover with latency penalty [OK]
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