social
Game Leaderboard
Per-game high scores, ranked with a secondary index on score.
Scores live under the game partition, and a GSI re-keys them by negated score so the top of the leaderboard is a single Query on the index.
The model
Score
A player's best score in a game.
- pk
- GAME#<gameId>
- sk
- PLAYER#<playerId>
Attributes: gameId (S), playerId (S), player (S), score (N)
Access patterns
- Query · GSI1Top scores for a game
List the highest scores in a game, ranked.
- GetItemGet a player's score
Fetch one player's score in a game.
Design notes
A GSI to rank, not to look upwhy
The base table answers get-a-player's-score by key. Ranking needs a different sort order, so a GSI re-keys every score under one partition per game, and the whole leaderboard is a single Query on the index.
Negate the score to rank descendinghow
A Query reads a partition in ascending sort-key order unless you pass ScanIndexForward false. Storing the negated score gets the same ranking from the default read, so every caller lands on the leaderboard order without having to remember the flag. The real, positive score stays in its own attribute for display.
Taught in the course
- The sort key is a query language - Conditions on the sort key narrow a Query before it reads, for free.
- A different key for a different question - A secondary index re-keys your items so you can Query them on a new axis.
These rows are real and already here. Running an operation against them downloads a DynamoDB-compatible engine, about 850 KB, and executes it in this tab.
List the highest scores in a game, ranked.
Run an operation to see the raw engine response.
Transactions, streams, tags and TTL are among the operations the in-browser engine doesn't implement yet.