Section 5: The Live Record and the Archive - Data Modeling
Executive Summary: A live game is one ~1 KB item in a regional key-value store, with moves packed into 2 bytes and clock readings into 3. One condition, ply = :n AND owner_epoch = :e, gives both ordering and fencing. Finished games move to a globally replicated archive; ratings and tournaments live in Postgres. Each store is chosen for one access pattern.
The interviewer taps the board. "You keep saying 'persist before broadcast'. Persist what, where?"
Start From the Reads and Writes
You: "Before I name a database, here are the six things the data has to do."
| # | Access pattern | Rate | Store |
|---|---|---|---|
| 1 | Append one move to one game | ~28K writes/s peak fleet-wide, ~11.2K/s in the busiest region | live_games |
| 2 | Load a game on failover | one read per game, ~5.6K games per crashed node | live_games |
| 3 | A user's recent games | paged, newest first | user_games |
| 4 | One game's full record and PGN | by game_id |
games |
| 5 | Read a rating at pairing, write it at game end | 16M updates/day, ~560/s peak | Postgres ratings |
| 6 | Rebuild tournament standings | on director restart | Postgres tournament_players + pairings |
Pattern 1 is the only hot one, and it must be strictly correct.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson