Video summary

Fortnite system design interview

Main summary

Key takeaways

Technology

Goal: Design Fortnite’s Leaderboard System (System Design Interview)

Requirements

  • Support at least 12 million concurrent online players.
  • Store per-player data:
    • Player score computed from kills + time survived
    • Persisted in a table initially.

Initial (Naive) Approach: Database + Counting

Design

  • Store each player’s score in a database column (e.g., scores) and index it.
  • To compute a player’s rank:
    • Count how many players have a higher score than the player.

Problem

  • Even with indexing, ranking at this scale becomes too slow.
  • Example claim: on a very large table (tens of millions of rows), counting can take ~35 seconds per query.
  • This is considered unacceptable for a real-time leaderboard.

Improved Approach: Redis Sorted Set

Design Change

  • Move scores out of the database into Redis for faster access.
  • Use a Redis sorted set:
    • Items remain sorted as writes happen, not during reads.
    • Internally uses a skip list to speed up rank lookup.

Expected Performance

  • Rank computation improves from seconds to ~milliseconds.

Handling Traffic Spikes: Sharding for Concerts/Events

Scenario

  • For events like a Travis Scott concert, assume 12 million players simultaneously.

Constraint

  • One Redis server caps at about ~100,000 writes/sec.

Solution: Shard the Leaderboard

  • Shard across multiple Redis servers.
  • Hash by player ID so writes distribute evenly.
  • Prevents any single server from becoming a bottleneck (“no server runs hot”).

Aggregation Strategy

  • Use an aggregator that periodically merges shard results, such as:
    • collecting each shard’s top players every few seconds.

Tradeoff

  • Players outside the “top” region may not receive an exact global rank.
  • Instead, they get an approximation such as:
    • “you beat 80% of players.”

Learning/Resource Mentioned

  • Mentions using learn.nextweek.org
    • Provides step-by-step guides for building projects
    • Includes documentation

Main Speakers / Sources

  • Interviewer / challenger:
    • Asks and critiques the candidate’s design (e.g., “Have you just lost your mind?”, “Try again.”)
  • Candidate:
    • Proposes the database-first approach
    • Then switches to Redis + sharding
    • Mentions the learning resource

Both appear to be the only speakers indicated in the subtitles.

Original video