SysPad › Examples › Real-time gaming leaderboard
Real-time gaming leaderboard
Score submissions go straight into a Redis sorted set (ZADD/ZRANGE/ZRANK) for O(log n) ranking; the database only sees a fraction, for durability.
A sorted set doing the actual ranking work, with the database relegated to an async durability path.
- Load: 25,000 req/sec
- First to saturate: Nothing at this load
- Estimated cost: $33k/mo
How it works
- Leaderboard (Sorted Set)
- The whole design lives here: ZADD updates a score and ZRANGE/ZRANK read a rank in O(log n), no scan. Both flows hit it - it is the superposition centre, not a cache in front of a slower store.
- Score History
- Durability only, and only for writes: a copy of each submission lands here off the hot path so the sorted set can be rebuilt if the cache is lost. Reads never touch it.
Request flows
Submit a score
- Client
- Load Balancer
- Leaderboard Service
- Leaderboard (Sorted Set)
- Score History
Read a rank
- Client
- Load Balancer
- Leaderboard Service
- Leaderboard (Sorted Set)
Lessons for this architecture
- Modelling users and traffic entry points
- How Application Load Balancer works
- How AWS Lambda works
- How Amazon ElastiCache works
- How DynamoDB works
Worked step by step
The same interview question, built up one twist at a time, with a simulation at each stage.