Design a Scalable Live Chess Platform

Design a real-time chess platform with matchmaking and multi-region recovery.

Introduction

30 Second Summary

A live chess match feels simple until players connect from different places through an unreliable network. Every screen must still show the same legal game at the same moment.

In this project, you will design a scalable live chess platform in draw.io. Your workbook will evolve a failing polling design into an authoritative multi-region architecture backed by scaling estimates.

What You'll Build

An interviewer can follow your workbook from an overloaded polling loop to a final regional design where every accepted move has one authoritative history.

By the end of this project, you'll have:

A final architecture you can trace from global matchmaking to one regional owner for each live game.
A move-flow explanation that traces durable commit before acknowledgement. A compact data model supports the story with User, Game, and Move records.
A two-minute talk track for defending the architecture with explicit scaling evidence.
Secret Mission: Defend the architecture after a lost move acknowledgement. Then recover one legal game history after an entire hosting region disappears.

Are there any prerequisites?

You need basic system design knowledge plus comfort reading boxes-and-arrows architecture diagrams. A Mac with browser access is enough because draw.io requires no desktop installation or account for this project.

Before We Start

This opening step locks the project scope to live chess gameplay and matchmaking before you begin diagramming. Each game needs one authoritative owner to serialize legal moves, maintain one clock state, and prevent conflicting game histories across regions.

Set Up Your System Design Workbook

A system design answer becomes hard to follow when its early sketch, failure analysis, and final architecture live in separate places. A single structured workbook keeps the design evolution visible.

In this step, you'll use draw.io to create one editable workbook on your Mac. The workbook will hold five named pages.

You'll also draw a client-to-server test flow on Naive V0. That quick check proves the file structure and canvas are ready.

In this step, get ready to:

Create a blank draw.io workbook using local-device storage.
Save the workbook as live-chess-system.drawio.
Build five named pages with a client-to-server canvas check.

Create a local workbook

The local-device path tells draw.io that this workbook belongs on your Mac. It avoids account setup.

Visit the official draw.io editor at https://app.diagrams.net/.
Choose the local-device storage option when draw.io asks where to store your diagrams.

The editor is now ready to create a diagram using local storage.

Click File in the top menu.
Select New.

You'll see the template library.

Select Blank from the template library.

You'll see an empty canvas. This becomes the first page of your workbook.

Save the editable file

The .drawio format keeps every page editable. Saving now gives the workbook a stable local filename before you add more content.

Click File in the top menu.
Select Save As.

The macOS save window lets you choose the workbook name and its local location.

Enter live-chess-system.drawio as the filename.
Choose a local folder on your Mac that you use for project files.
Confirm the save in the macOS window.

You'll see live-chess-system.drawio as the current diagram name in draw.io. Good progress. Your interview workbook now has a local editable home.

Can't Find the Saved Workbook?

Check that the filename ends with .drawio.
Repeat the save into a local folder that you can find again.

Still stuck? Help me locate or resave my draw.io workbook.

Organize the pages and test the canvas

Each page gives one part of your interview story a stable home. This structure lets an interviewer follow the design from the naive version to the final architecture.

How the Workbook Is Organized

The Naive V0 page holds the first single-region design.
The Final Architecture page holds the scalable design.
The Move Sequence page holds the accepted-move flow.
The Data Model page holds the logical records.
The Interview Notes page holds the final explanation.

Right-click the existing page tab at the bottom of the editor.
Select Rename.

You'll see the page rename dialog.

Enter Naive V0 as the page name.
Click Rename.

You'll see Naive V0 on the first page tab.

Add four more pages by clicking the + symbol four times in the page tab bar.

You'll see five page tabs along the bottom of the editor.

Repeat the same rename flow for each new tab in the order shown above.

Your tabs should now read Naive V0, Final Architecture, Move Sequence, Data Model, and Interview Notes.

Select the Naive V0 page tab.
Drag one rectangle from the left-side shape library onto the canvas.

You'll see the first rectangle on the Naive V0 canvas.

Double-click the first rectangle.
Enter Client as its label.

You'll see Client inside the first rectangle.

Drag a second rectangle from the left-side shape library onto the canvas.
Double-click the second rectangle.

The label editor is active on the second rectangle.

Enter Server as its label.
Create the client-to-server arrow by dragging a connector from the Client rectangle to the Server rectangle.

You'll see two labeled rectangles with one connector pointing from Client to Server.

That first flow is working. Your workbook now has a concrete starting point for the architecture that later steps will challenge.

The browser canvas now holds your tool check. Save again so the local workbook includes the page structure and connector.

Click File in the top menu.
Select Save As.

The macOS save window opens with your current workbook ready to save.

Keep live-chess-system.drawio as the filename.
Confirm that the existing local file should be replaced.

Your updated workbook is now saved locally. Every page and the first client-to-server flow are preserved in one editable file.

Before you click through the tabs, which page do you expect to hold the only diagram?

Click each of the five page tabs once.
Return to the Naive V0 page.

You'll see all five named tabs remain visible. The other four pages are blank and ready for their diagrams.

Trace the connector from the Client rectangle to the Server rectangle.

You'll see one client-to-server arrow with no missing or unlabeled shape. This confirms the workbook structure and canvas are ready.

✔️ Awesome, I've got everything!

Your local editable workbook contains all five pages. The Naive V0 page also shows the client-to-server test flow.

ⓧ I'd like to double check my workbook

Compare your workbook with this checkpoint:

Confirm the local editable file is named live-chess-system.drawio.
Confirm the page tabs are named Naive V0, Final Architecture, Move Sequence, Data Model, and Interview Notes.
Confirm Naive V0 contains rectangles labeled Client and Server with one connector from client to server.
Confirm the other four pages are present and ready for diagrams.

Your system design workbook is ready. Next up, you'll turn Naive V0 into the smallest working live chess architecture.

Build the Naive Single-Region Design

Your draw.io workbook already keeps the design journey in one editable place. The first real page now needs a working baseline that an interviewer can follow.

Starting with the smallest single-region architecture creates an early visible win. It gives you a concrete polling design to challenge before complexity appears.

In this step, get ready to:

Define the live gameplay requirements.
Record explicit scaling assumptions.
Draw a traceable single-region polling path.

Define the design boundary

Requirements scoping keeps every box tied to live gameplay or matchmaking. The boundary stops unrelated product features from crowding the interview story.

Switch back to the Naive V0 page in the workbook from earlier.
Drag a text shape from the left-side shape library onto the upper-left area of the canvas.
Enter these lines in the first text shape: In Scope Rating and time-control matchmaking Legal move submission Authoritative results Clocks Persistence Reconnects.
Confirm the first text shape shows one heading plus six requirements.

You should see a compact list covering matchmaking, moves, results, clocks, persistence, and reconnects.

Drag a second text shape below the first scope box.
Enter these lines in the second text shape: Out of Scope Puzzles Tournaments Social feeds Chat Spectators Anti-cheat.
Confirm both scope boxes remain separate from the architecture shapes.

That boundary is now visible. Every architecture decision on this page can stay focused on live gameplay or matchmaking.

Record the scaling assumptions

Back-of-the-envelope estimation starts with explicit assumptions. These numbers make later calculations defensible during an interview.

Drag a wide text shape onto the upper-right area of the Naive V0 canvas.
Enter these lines in the assumptions shape: Interview Assumptions Peak concurrent players: 1,000,000 Active in games: 60% Players per game: 2 Polling frequency: one poll every 2 seconds per active player Accepted move rate: 6 per game per minute at peak Games per day: 3,000,000 Moves per game: 40 Stored Move record: 500 bytes.
Confirm the assumptions shape contains all eight values.

You now have a visible calculation contract. Every load estimate in the next step can point back to these assumptions.

Draw the single-region polling path

A naive single-region architecture sends every live action through one regional path. The application server handles matchmaking plus game logic.

A database stores the game state at the end of that path.

Select the existing client rectangle.
Change its label to Player A Client.
Select the existing server rectangle.
Change its label to Regional Endpoint.
Confirm the original connector still joins Player A Client to Regional Endpoint.

The original tool check now forms the first segment of your real architecture.

Drag a new rectangle below Player A Client.
Label the new rectangle Player B Client.
Confirm the two client rectangles form a vertical pair.

You should now see both players entering the same regional path.

Drag a new rectangle to the right of Regional Endpoint.
Enter these lines in the new rectangle: Application Server Matchmaking Game Logic.
Confirm both responsibilities are visible inside the application server.

The central server now shows where players are paired. It also shows where moves are processed.

Drag one final rectangle to the right of Application Server.
Label the final rectangle Database.
Confirm the component order runs from clients to the regional endpoint to the application server to the database.

Your component chain is complete. The next connectors make requests plus repeated updates visible.

Connector labels can feel fiddly because a crowded line is harder to select. Each label below has one job in the request path.

Select the existing connector from Player A Client to Regional Endpoint.
Enter this two-line connector label: Move submission request Poll request every 2s.
Confirm the connector points toward Regional Endpoint.
Add a connector from Player B Client to Regional Endpoint using the connector tool.
Enter this two-line connector label: Move submission request Poll request every 2s.
Confirm both clients send labeled requests to the same endpoint.

Both players now submit moves through requests. They also ask for game updates every two seconds.

Add a return connector from Regional Endpoint to Player A Client.
Label the return connector Game update response.
Confirm the two connectors form a complete polling loop for Player A.
Add a return connector from Regional Endpoint to Player B Client.
Label the return connector Game update response.
Confirm the two connectors form a complete polling loop for Player B.

The repeated update path is now visible for both players. Each client asks for state before the endpoint returns a response.

Add a connector from Regional Endpoint to Application Server.
Label the connector Forward request.
Confirm the connector points toward the application server.
Add a connector from Application Server to Database.
Label the connector Read / write game state.
Confirm the connector points toward the database.

What does the naive path show?

The Move submission request label shows that a player action travels through the regional endpoint.
The Poll request every 2s label creates a repeated request loop for each player.
The Game update response label carries the latest state back to each player.
The Matchmaking label places opponent pairing inside the application server.
The Game Logic label places move processing inside the same server.
The Database label marks the persistent state dependency.

Save your changes to live-chess-system.drawio using the workbook's save control.

Before you trace the design, consider whether every move request reaches matchmaking before both polling loops return an update.

Trace Player A Client through Regional Endpoint into Matchmaking.
Follow the Move submission request into Game Logic.
Follow the Poll request every 2s loop back to Player A Client.
Follow the Poll request every 2s loop back to Player B Client.
Check every component plus connector for a visible label.

You should reach Matchmaking inside Application Server through Regional Endpoint. The move submission request should continue to Game Logic.

Each two-second polling loop should return a labeled game update to its player.

Can't trace the complete path?

Check that both client connectors point toward Regional Endpoint.
Add any missing Game update response connector from the endpoint back to its client.
Check that Application Server visibly contains both Matchmaking plus Game Logic.
Still stuck? Help me troubleshoot my Naive V0 draw.io architecture.

Your naive version is now a traceable working baseline. Next, you'll quantify its load before exposing the failures hidden inside it.

Expose the Naive Design Failures

Your browser-based draw.io workbook now shows a complete single-region flow from matchmaking to repeated game updates. That visible path gives you a concrete design to pressure-test.

The repeated polling loop makes the design look simple. Peak traffic exposes a large request gap.

The page also has no clear owner for clocks or game state. Retries, reconnects, and a regional outage expose failures the diagram currently hides.

In this step, get ready to:

Quantify the polling overhead against useful move traffic.
Annotate failures in clock authority, ownership, retries, and reconnect recovery.
Show why the single hosting region creates total unavailability.

Quantify the traffic gap

A back-of-the-envelope estimate turns each traffic assumption into a defensible load figure. The comparison reveals how much work comes from checking for updates instead of playing moves.

Before you calculate, do you expect polling requests or accepted moves to dominate the peak load?

Create a red calculation callout on Naive V0 using the editor's style controls.
Add 600,000 active players = 1,000,000 × 60% to the callout.
Add 300,000 active games = 600,000 ÷ 2 to the callout.
Add 300,000 poll requests/s = 600,000 ÷ 2 seconds to the callout.
Add 30,000 accepted moves/s = 300,000 × 6 ÷ 60 to the callout.
Add At least 60,000 player update messages/s = 30,000 × 2 to the callout.
Add 120,000,000 stored moves/day = 3,000,000 × 40 to the callout.
Add About 60 GB/day raw before indexes, replication, and backups = 120,000,000 × 500 bytes to the callout.

You'll see ten poll requests for every accepted move at peak. The traffic is dominated by checking for updates.

What Do the Estimates Reveal?

The 300,000 poll requests/s figure is ten times the accepted move rate.
The at least 60,000 player update messages/s figure assumes one update for each player after every accepted move.
The about 60 GB/day figure covers raw Move records before additional storage overhead.

Inject gameplay state failures

Traffic alone does not explain whether a game remains correct. Missing authoritative state means no component has final say over the current position or server clock.

Place a red callout beside the player clocks that says Clock drift: each client can show a different remaining time. No component is named as clock authority..
Place a red callout beside the application server that says Scale-out conflict: two application nodes can accept conflicting next-turn state because no explicit game owner exists..
Place a red callout beside the polling return path that says Stale reconnect state: a returning player can resume from an old position with no clear recovery source..
Place a red callout beside the move request that says Lost move response: retrying the same move can apply a duplicate because duplicate detection is absent..
Keep all four callouts framed as unresolved failures on Naive V0.

Why Do These Failures Compound?

Without authoritative state, application nodes can disagree about which move is next. Client clocks can also drift away from the accepted game history.

Missing idempotency turns one successful move with a lost response into two possible state changes.

Missing reconnect recovery leaves a returning player without a trusted path back to the latest position.

You have now made the correctness gaps visible. Each incident shows a specific way the naive design can produce an unclear game history.

Expose the regional failure

The regional endpoint, application server, and database all sit inside one failure domain. A regional outage therefore removes the entire gameplay path.

Place a red callout across the regional path that says Single-region outage: matchmaking, move submission, clocks, persistence, and reconnects all become unavailable..
Save your changes to live-chess-system.drawio using the same local save flow from earlier.

Before you trace the finished page, which failure do you think makes the strongest case for changing the architecture?

Trace one player from matchmaking through the regional endpoint to the application server.
Compare the peak polling rate with the accepted move rate in the red calculation callout.
Read the red incident callouts around the clocks, application server, reconnect path, and move request.
Confirm that the regional outage callout covers the entire gameplay path.

You'll see 600,000 active players, 300,000 active games, 300,000 poll requests/s, 30,000 accepted moves/s, at least 60,000 player update messages/s, 120,000,000 stored moves/day, and about 60 GB/day of raw Move records.

You'll also see failures for clock authority, game ownership, conflicting turns, stale reconnect state, duplicate retries, and total regional unavailability.

Callouts Hard to Scan?

Increase each callout's text size until every label is readable at the page's normal zoom level.
Move overlapping callouts into empty space beside the component they describe.
Still stuck? Help me organize my Naive V0 failure callouts in draw.io.

Strong work. Your Naive V0 page now fails through measurable load, ambiguous game state, recovery gaps, and regional loss.

Next, you'll replace the polling path with persistent connections plus one authoritative game owner.

Add an Authoritative Real-Time Core

Your draw.io workbook now proves that polling creates ten times more requests than accepted moves. The same page shows that missing ownership creates disputed game state.

Persistent two-way connections remove the repeated poll loop. Each accepted move can now travel through one live path.

An authoritative game owner decides each accepted transition. It records move order.

The owner also records both server-controlled clocks. Retries return to that owner for the existing result.

Reconnects use the same source to recover current state. This step turns those rules into the core architecture.

In this step, get ready to:

Separate live connection handling from stateless matchmaking and lookup paths.
Trace one accepted move from receipt to state delivery.
Define the logical records that support ordering and deduplication.

Build the authoritative architecture

A live game needs a stable route from each player to its current owner. The Game Directory resolves that route without placing game state inside the gateways.

Switch back to the Final Architecture page tab.
Add a left-side rectangle labeled Player Client A.
Add a second left-side rectangle labeled Player Client B.

You should see two separate players ready to enter the platform.

Add a center-left rectangle labeled Connection Gateways.
Connect each player box to Connection Gateways with a connector labeled Persistent two-way connection.

The two players should now share a live gateway path without a polling loop.

Add a rectangle above the gateways labeled Stateless Matchmaking API.
Add another rectangle beside it labeled Stateless Lookup API.

The final architecture should now show separate stateless request paths beside the live gateway path.

Connect the player side to both API boxes with connectors labeled Matchmaking and lookup requests.
Add a center-right rectangle labeled Authoritative Game-Service Pool.

You should see the live game service separated from matchmaking and lookup work.

Connect Connection Gateways to Authoritative Game-Service Pool with a connector labeled Route to authoritative owner.
Add a box below the gateways labeled Game Directory with the subtitle game_id maps to one owner and owner_epoch.

The directory now makes ownership explicit for every active game.

Connect Connection Gateways to Game Directory with a connector labeled Find owner by game_id.
Connect Game Directory to Authoritative Game-Service Pool with a connector labeled Exactly one writable owner per game.

You should be able to trace a gateway lookup to one current owner with one owner epoch.

Add a right-side rectangle labeled Durable Game Store or Event Log.
Connect Authoritative Game-Service Pool to the durable store with a connector labeled Commit Move and Game version before acknowledgement.

Your architecture now has a clear path from connected players to one owner. Accepted state reaches durable storage before any player receives success.

Why persistent connections instead of polling?

Polling creates recurring requests even when neither player moves. A persistent connection lets the server push accepted state through an existing channel.

Stateless APIs still suit matchmaking and lookup requests. Those paths do not own the changing position of a live game.

Map the accepted move

Idempotency gives a repeated request the same intended server effect as its first attempt. A stable move_id lets the owner recognize that repetition.

The durable commit must finish before the acknowledgement. The same rule applies before state is pushed to either player.

Switch back to the Move Sequence page tab.
Add a participant row from left to right labeled Player A, Player B, Connection Gateway, Game Directory, Authoritative Game Owner, and Durable Game Store or Event Log.
Extend one vertical lifeline below each participant.

You should see six vertical lanes with time flowing from top to bottom.

Add a message from Player A to Connection Gateway labeled game_id, move_id, expected_version, from_square, to_square, promotion_piece.
Add a message from Connection Gateway to Game Directory labeled Find owner for game_id.

The opening messages should show the move arriving before the gateway resolves its destination.

Add a return message from Game Directory to Connection Gateway labeled owner and owner_epoch.
Add a message from Connection Gateway to Authoritative Game Owner labeled Route move to current owner.

The gateway should now route the move to the single owner recorded by the directory.

Add a self-message on Authoritative Game Owner labeled Authenticate player.
Add the next self-message labeled Deduplicate (game_id, move_id).

Authentication establishes who sent the move. Deduplication checks whether that move was already accepted.

Add the next self-message labeled Validate expected_version.
Add the next self-message labeled Validate turn and legality.

The owner should reject stale state before applying the move to the current legal position.

Add the next self-message labeled Update server clock.
Add a message from Authoritative Game Owner to Durable Game Store or Event Log labeled Durably commit Move and Game version.

The clock update and resulting position now belong to one atomic accepted transition.

Add a return message from the durable store to the owner labeled Commit confirmed.
Add a message from the owner to the gateway labeled Acknowledge mover.

The acknowledgement should appear below the durable confirmation. This ordering prevents an uncommitted move from looking accepted.

Add a message from the gateway to Player A labeled Accepted result.
Add a second message from the owner to the gateway labeled Push new state.

The mover now receives an acknowledgement after the move is safe.

Add messages from the gateway to both player lifelines labeled New authoritative state.
Add a note beside the deduplication step labeled Existing (game_id, move_id): return existing result. No new Move. No clock advance. No version advance.

Both players should receive the same committed state. A repeated move should stop at the deduplication result.

Why commit before delivery?

A delivered update could disappear after a crash if its state was never committed. Durable state decides whether the platform accepted the move.

Acknowledging after the commit lets a retry find the existing result. The game history advances once.

Sequence arrows hard to follow?

Keep every later action below the action that must finish first.
Place Commit confirmed above the acknowledgement and both state pushes.
Still stuck? Help me check the ordering in my authoritative chess move sequence.

Define the game data model

A logical data model captures the state needed to rebuild a game. Its keys also protect accepted move order and duplicate handling.

Switch back to the Data Model page tab.
Add an entity box containing User(user_id, rating, created_at).
Add an entity box containing Game(game_id, white_user_id, black_user_id, status, host_region, position, next_turn, white_clock_ms, black_clock_ms, version, last_move_seq).

The model should now identify each player and capture the current authoritative game snapshot.

Add an entity box containing Move(game_id, sequence_no, move_id, player_id, from_square, to_square, promotion_piece, server_received_at, resulting_version).
Add a note beside Move labeled Ordering key: (game_id, sequence_no).

The Move record now preserves an ordered history for each game.

Add another note beside Move labeled Deduplication key: (game_id, move_id).

You should see one key for accepted order and one key for recognizing a repeated client request.

What do these fields protect?

The (game_id, sequence_no) key fixes every accepted move at one position in a game's history.
The (game_id, move_id) key recognizes a retry of an existing move.
The version fields stop a stale transition from replacing newer game state.

Open the save action by pressing Cmd+Shift+S on your Mac.

You should see your browser's local save prompt for the workbook.

Keep live-chess-system.drawio as the filename.
Save the workbook to its existing local location on your Mac.

Your local workbook now contains the authoritative architecture, accepted-move sequence, and logical data model.

Before you trace the retry, do you expect it to reach the durable commit a second time?

Return to the Move Sequence page tab.
Trace the first attempt from Player A through the durable commit.

You should reach one committed Move before the mover receives an acknowledgement.

Trace a retry carrying the same move_id through the deduplication step.

The retry should return the existing result before another commit. The move sequence and server clock should remain unchanged.

That is the central contract secured. One owner now decides each move from committed state.

Next, you'll spread game hosting across regions while preserving this single authoritative history.

Scale Across Regions and Rehearse

Your draw.io workbook now gives every active game one authoritative owner. That owner controls legal move order plus both clocks.

A single hosting region still creates one failure domain. You will use multi-region routing to spread game hosts across regions while keeping matchmaking logically shared.

The final pass adds recovery rules plus a concise interview story. You will finish with an exported architecture that you can present in under two minutes.

In this step, get ready to:

Expand the final architecture with shared matchmaking plus regional game hosting.
Document reconnect recovery plus safe ownership transfer.
Prepare an interview package with final calculations, a PNG export, plus a two-minute talk track.

Expand the architecture across regions

A global entry layer gives both players one route into the platform. Matchmaking creates the pair before placement chooses one hosting region for their game.

Switch back to the Final Architecture page in the existing workbook.
Drag a rectangle from the left shape library above the existing connection gateways.
Label the rectangle Global Entry Layer.
Trace each player connection through Global Entry Layer to a connection gateway.

You should now see both players enter through one global layer before reaching the persistent-connection gateways.

Drag a rectangle beside the existing matchmaking components.
Label the rectangle Logically Shared Matchmaking Pool: rating + time control.

The diagram now shows one candidate pool that forms a match before any regional owner is selected.

Draw a connector from Global Entry Layer to the logically shared matchmaking pool.
Add a note labeled Latency Observations beside the shared pool.

You should see match inputs reach the shared pool. The latency information remains separate from rating plus time-control matching.

Add a rectangle after the shared matchmaking pool.
Label the rectangle Placement: choose one hosting region for both players.

The placement decision now has a visible position after match formation.

Draw a connector from the shared matchmaking pool to the placement decision.
Draw a connector from Latency Observations to the placement decision.

You should be able to trace rating plus time-control matching first. Regional placement follows as a separate decision.

Duplicate the existing authoritative game-service pool until three regional pools are visible.
Label the pools Regional Game-Service Pool A, Regional Game-Service Pool B, plus Regional Game-Service Pool C.

Your canvas should now show three distinct places where one game can be hosted.

Connect the placement decision to the Game Directory.
Label that connector Record one host region.

The Game Directory now records the single hosting decision for both players.

Draw an owner-routing connector from the Game Directory to each regional game-service pool.
Draw a durable-state connector from each regional pool to the existing durable game store or event log.
Trace the active-game path from each gateway through the Game Directory to one regional owner.

You should see every active game reach exactly one regional owner. Each regional pool should also reach the same durable recovery source.

Why match before placement?

Rating plus time control create the opponent pair. Keeping this pool logically shared preserves the full set of available opponents.

Placement then uses latency observations to choose one region for both players. The Game Directory records that owner so every later move reaches the same game history.

Can't trace one clear regional path?

Check that the shared matchmaking pool connects to placement before the Game Directory records an owner.
Check that the Game Directory has a route to all three regional pools.
Still stuck? Help me simplify my multi-region chess architecture diagram.

Document recovery and ownership rules

A reconnect request carries game_id plus last_seen_sequence. The Game Directory routes the player to the recorded owner.

The owner returns a current snapshot plus any missing moves. This gives the player a complete recovery path from a known sequence.

Switch back to the Interview Notes page.
Add a Reconnect and Recovery panel that captures game_id, last_seen_sequence, recorded-owner routing, plus a snapshot with missing moves.

You should now have a recovery path that starts with the player's last confirmed sequence. It ends with a complete authoritative view.

Retry safety depends on idempotency. The owner deduplicates repeated requests using (game_id, move_id).

A higher owner epoch fences a stale host after ownership changes. A replacement owner rebuilds the game from durable state before accepting new moves.

Add a Write Safety and Host Recovery panel that covers retry deduplication plus stale-version rejection.
Include owner-epoch fencing plus replacement-owner reconstruction from durable state in the same panel.
Trace a reconnect from last_seen_sequence to the snapshot plus missing moves.
Trace a host failure from the higher owner epoch to the reconstructed replacement owner.

The first trace should restore a player without losing accepted moves. The second trace should leave only the replacement owner able to accept writes.

How does the owner epoch protect the game?

A higher epoch identifies the current owner after recovery. Requests from a host with an older epoch are rejected.

This fencing rule prevents split-brain writes from creating two move orders or two clock histories.

Recovery notes feel disconnected?

Start each recovery path with the event the player or host experiences.
End each path at the authoritative snapshot or replacement owner.
Need another review? Help me check my reconnect and owner-epoch recovery notes.

Add the calculations and rehearse the story

The final notes need enough arithmetic to defend the architecture. They also need a clear order that fits a short interview answer.

Final calculation panel

Peak concurrency assumption: 1,000,000 peak concurrent players.
Active gameplay assumption: 60% in active games.
Active load: 600,000 active players.
Game count: 300,000 active games.
Naive polling load: 300,000 poll requests/s.
Useful move traffic: 30,000 accepted moves/s.
Player delivery traffic: at least 60,000 player update messages/s.
Daily game assumption: 3,000,000 games per day.
Move-count assumption: 40 moves per game.
Daily storage volume: 120,000,000 stored moves per day.
Raw record size: 500 bytes per stored Move record.
Raw Move storage: about 60 GB per day. This excludes indexes, replication, plus backups.

Add a Final Calculations panel to Interview Notes using the values above.
Compare 300,000 poll requests/s with 30,000 accepted moves/s inside the panel.

The comparison should make the naive polling overhead visible at a glance.

Two-minute talk track order

Define the scope as live gameplay plus matchmaking.
State the peak concurrency plus active-game assumptions.
Compare naive polling load with accepted move traffic.
Explain why one authoritative owner controls legal state plus clocks.
Trace durable commit before acknowledgement plus player updates.
Explain shared matchmaking before single-region placement.
Cover reconnect recovery plus retry deduplication.
Describe owner-epoch fencing plus durable host reconstruction.
Close with consistency, availability, plus operational-complexity trade-offs.

Add a Two-Minute Talk Track panel to Interview Notes using the order above.
Read the panel once to confirm every point connects to a visible page in the workbook.

Your notes should now move from requirements to estimates. They should finish with failure handling plus explicit trade-offs.

Open the save action by pressing Cmd+Shift+S.
Save the updated local workbook as live-chess-system.drawio.
Confirm that Finder shows the updated local editable workbook.

Your editable workbook now contains the complete design plus the interview explanation.

Return to the Final Architecture page.
Click File in the editor menu.
Select Export As.
Select PNG.
Click Export.
Use the macOS save dialog to store the export as live-chess-final-architecture.png.

Before you open the export, do you expect the complete path from shared matchmaking to one regional owner to be traceable without using the notes page?

Open live-chess-final-architecture.png in Finder.
Trace matchmaking by rating plus time control before the placement decision.
Trace placement through the Game Directory to one regional game-service pool.
Confirm that at least three regional pools plus durable state are visible.

You should see match formation happen before placement. The placement path should select one hosting region for both players.

Before you start the timer, do you expect the full explanation to fit within two minutes?

Set a two-minute timer on your phone.
Deliver the talk track while viewing live-chess-final-architecture.png.

Your explanation should finish before the timer ends. It should name one consistency trade-off, one availability trade-off, plus one operational-complexity trade-off.

Export missing part of the design?

Confirm that Final Architecture was the active page when you selected the export option.
Confirm that every regional pool sits inside the visible page area.
Need help? Help me troubleshoot my draw.io PNG export.

That completes your interview package. You can now present the architecture from naive polling through safe multi-region ownership.

Secret mission

Defend the Design During Two Failures

A committed Move loses its acknowledgement. Then its hosting region disappears. Defend one legal game history through both incidents without relying on your prepared notes.

Clean Up Your Resources

Your draw.io project is stored entirely on your Mac with no ongoing cloud costs. Choose a cleanup option below.

Resources you used:

The editable live-chess-system.drawio workbook containing all five pages plus the failure-defense notes.
The presentation-ready PNG export named live-chess-final-architecture.png.

Keep everything running

Keep both local files if you want to refine the architecture or practise the interview explanation again.

Retain live-chess-system.drawio so every diagram page remains editable.
Retain live-chess-final-architecture.png so the final architecture remains ready to present.

Pause - I'll come back to this later

Close the browser editing session while keeping both saved files on your Mac.

Close the draw.io browser tab.
Keep live-chess-system.drawio for your next editing session.
Keep live-chess-final-architecture.png as a presentation copy of the final design.

Your saved workbook preserves the architecture pages plus the final failure-defense callout.

Delete - I don't want to use this again

Remove both local artifacts if you no longer need the editable workbook or its exported architecture.

Open Finder from the Dock.
Search your Mac for live-chess-system.drawio.
Drag the matching file to Trash in the Dock.
Search your Mac for live-chess-final-architecture.png.
Drag the matching file to Trash in the Dock.

Both project files remain recoverable until you empty Trash. Emptying Trash permanently removes every item currently inside it.

Open Trash from the Dock.
Confirm that live-chess-system.drawio is present.
Confirm that live-chess-final-architecture.png is present.
Check that Trash contains no other files you need.
Empty Trash.
Search your Mac for live-chess-system.drawio.
Search your Mac for live-chess-final-architecture.png.

You should see no matching file for either search.

Nice Work!

Excellent work! Your editable live-chess-system.drawio workbook in draw.io now presents a complete journey from a failing first design to regional game hosting with one authoritative owner per game.

You've learned how to:

Challenge a naive polling design with explicit assumptions. Show why 300,000 poll requests/s overwhelms 30,000 accepted moves/s.
Create an authoritative move flow that commits each Move before acknowledgement. Deduplicate retries with (game_id, move_id). Represent gameplay state with a compact User/Game/Move data model.
Evolve the platform into a multi-region architecture with one logically shared matchmaking pool. Assign one hosting region to each game. Explain safe recovery through owner epochs plus durable state. Export the final diagram as live-chess-final-architecture.png for an interview walkthrough.
Complete the Secret Mission by defending a lost acknowledgement without applying one move twice. Recover from a regional outage without allowing split-brain writes.

Ready to quiz yourself?