04QuestionsOnline chess

04 · Worked prompt

Online chess

Design authoritative game state, matchmaking, move validation, clocks, reconnection, and spectator fan-out.

30 minInterview blueprint

INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

20pts
Scope the problem
0–5 min
Prioritize the core flows, state the scale, and name the non-goals.
15pts
Define contracts
5–10 min
Identify durable entities, APIs, idempotency, and the source of truth.
30pts
Complete the diagram
10–25 min
Trace one write path and one read path. Label the commit boundary and async work.
20pts
Lead one deep dive
25–38 min
Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.
15pts
Prove reliability
38–45 min
Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design authoritative game state, matchmaking, move validation, clocks, reconnection, and spectator fan-out.

Online chess system architecture. A single game owner validates moves and clocks; every client repairs from an ordered move log. Request path: Players + spectators to Realtime edge to Game owner to Move log. Asynchronous path: Game topic to Rating + archive. Read path: Game read API to Game snapshot. External dependency: Matchmaker. Delivery path: Game fan-out. — Online chess · system architecture

DEFEND THE DIAGRAM

Explain every boundary before adding more boxes.

A single game owner validates moves and clocks; every client repairs from an ordered move log.

INTERVIEW CONTRACT

Design authoritative game state, matchmaking, move validation, clocks, reconnection, and spectator fan-out.

CAPACITY QUESTIONS TO QUANTIFY

Millions users · tight interaction p99 · spectator spikes · durable game history. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

End-to-end walkthrough

Trace the architecture in this order.

01
Enter and classify the request
Players + spectators → Realtime edge
Moves, clocks, reconnect enters over HTTPS / RPC. Realtime edge handles identity, admission, routing, and request context; it deliberately does not own domain truth.
02
Validate, then cross the commit boundary
Realtime edge → Game owner → Move log
Game owner receives the move(seq), checks invariants and retry identity, then uses append legal move to update Move log. The user-visible mutation is accepted only after this boundary succeeds.
03
Move replayable work off the request path
Game owner → Game topic → Rating + archive → Game snapshot
Game owner emits publish after commit; Rating + archive uses consume and project / update to build Game snapshot. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
04
Serve reads from the right authority
Realtime edge → Game read API → Game snapshot / Move log
Game read API uses optimized read for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
05
Contain the dependency boundary
Game owner → Matchmaker
dependency call crosses into Matchmaker. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.
06
Deliver without changing the source of truth
Rating + archive → Game fan-out → Players + spectators
Rating + archive uses publish move; Game fan-out returns updates over WebSocket. Sequence IDs, reconnect cursors, and backpressure make delivery resumable without turning a socket into durable state.

Ownership ledger

Why each box exists—and what it must defend.

Component	Owns	Why it exists	Interviewer probe
Realtime edgeAuth + connection routing	Identity, admission, routing	Protects the system edge and attaches trusted context before domain work begins.	Timeout budgets, quotas, regional routing
Game ownerRules + sequence + clock	Write invariants and retry identity	Serializes or conditionally applies state changes before acknowledging success.	Concurrent writes, deduplication, hot ownership
Move logAuthoritative transitions	Authoritative durable state	Provides the one record used to resolve disputes, recover, and rebuild projections.	Partition key, replication, consistency
Game topicOrdered committed moves	Durable asynchronous handoff	Absorbs bursts and lets slow or optional work retry independently of the request.	Ordering key, lag, retention, dead letters
Rating + archivePost-game side effects	Replayable processing	Runs expensive, fan-out, or side-effecting work with leases and bounded retries.	Idempotency, poison work, autoscaling
Game snapshotFEN + clocks + seq	Rebuildable query state	Shapes data for the dominant reads without weakening the write-side invariant.	Freshness, versioning, rebuild time
Game read APIPosition + replay cursor	Read composition and freshness policy	Chooses authoritative or derived state and returns a stable client contract.	Fan-out, cache policy, partial results
MatchmakerPairing + game assignment	External capability, not local truth	Keeps a specialized or third-party concern behind a replaceable contract.	Ambiguous timeout, circuit breaking, fallback
Game fan-outMove and clock events	Connection and delivery state	Separates open connections and fan-out pressure from durable domain state.	Reconnect, ordering, slow consumers

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage: PostgreSQL/distributed SQL stores games, moves, and rating changes; Redis stores match queues and connection routing; object storage keeps archives.
Partitioning / sharding: Hash by game_id and route one game to one fenced owner. Index user history separately by player_id; isolate tournament partitions when needed.
Indexes: Unique (game_id, sequence) and (game_id, command_id); player history by (player_id, finished_at DESC); active owners by heartbeat.
Replication + consistency: Moves and clocks are linearized and synchronously committed by the game owner. Spectator streams and ratings update asynchronously.
Cache, queue + recovery: Game-keyed events fan out through pub/sub. Cache current snapshots for spectators, but validate moves only against the owner/version.
Capacity math: Estimate concurrent games, moves/sec, top-match spectator fan-out, clock precision, reconnect load, and regional egress.
Alternative rejected: Multi-writer row updates create move/clock races; one fenced owner plus an append log makes legality and order explicit.

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Clock authority

Store last committed clock values and monotonic server timestamp

Client countdowns are presentation, not truth

Game ownership

Use one regional owner with a fenced lease and append log

Multi-leader move acceptance creates an avoidable split-brain

Spectators

Fan out committed events through regional gateways and let clients repair by sequence

Spectator scale must not affect move acceptance

Failure pressure test

Show detection, containment, recovery, and evidence.

Owner loss

Acquire fenced ownership and rebuild from snapshot plus log

failover time and stale-owner writes

Duplicate move

Reject repeated client operation ID and expected sequence

duplicate submissions

Client disconnect

Keep clock policy explicit and allow event replay

reconnect rate and forfeits

Before you finish, explicitly cover

Functional requirements and non-goals
Peak traffic, storage, bandwidth, and growth
Entities, APIs, idempotency, and pagination
Source of truth and consistency promise
Partition key, replicas, caches, and hot spots
Retries, backpressure, failover, and reconciliation
Latency, saturation, correctness, and recovery metrics
Security, migration, cost, and multi-region evolution

SAY THIS WHILE YOU DRAW

A four-part talk track

Scope
“I’ll prioritize match players and create games and validate legal moves and authoritative clocks.”
Scale
“The design changes around millions users · tight interaction p99 · spectator spikes · durable game history.”
Decision
“One authoritative owner per game prevents split-brain; regional ownership lowers latency.”
Risk
“The first failure I want to pressure-test is: Reconnect, duplicates, and clock skew can create divergent boards or unfair timeouts.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements

Match players and create games
Validate legal moves and authoritative clocks
Reconnect without losing sequence
Support spectators and rating updates

Online chess · state lifecycle

state lifecycle

Each transition must be durable, observable, and safe to retry.

waiting

active

checkmate or draw

abandoned

finalized

02Data model and APIs4 entities · 3 interfaces

Core entities

Gamegame_id, players, position, clock_state, sequenceOwner: Game authority

Movegame_id, sequence, notation, received_atOwner: Game event log

MatchTicketplayer_id, rating, region, created_atOwner: Matchmaker

RatingUpdategame_id, before, after, statusOwner: Rating worker

External interfaces

POST /v1/games/{id}/moves

Submit a move against expected sequence

GET /v1/games/{id}/events?after={sequence}

Replay moves and clock events

POST /v1/matchmaking/tickets

Enter a region and rating-aware pool

03Deep dives and trade-offsChoose one

Clock authority

Store last committed clock values and monotonic server timestamp

Client countdowns are presentation, not truth

Game ownership

Use one regional owner with a fenced lease and append log

Multi-leader move acceptance creates an avoidable split-brain

Spectators

Fan out committed events through regional gateways and let clients repair by sequence

Spectator scale must not affect move acceptance

04Failures, recovery, and evidence3 scenarios

Owner loss

Acquire fenced ownership and rebuild from snapshot plus log

failover time and stale-owner writes

Duplicate move

Reject repeated client operation ID and expected sequence

duplicate submissions

Client disconnect

Keep clock policy explicit and allow event replay

reconnect rate and forfeits

05What makes the answer seniorInterviewer signals

The game server—not the browser—owns the clock
Use sequence numbers for both correctness and reconnect repair
Keep ratings asynchronous and idempotent after a finalized result
Primary trade-off: One authoritative owner per game prevents split-brain; regional ownership lowers latency.

BEFORE THE NEXT QUESTION

Can you redraw it from memory?

Name the source of truth.
Trace the write and read paths.
Defend one trade-off.
Recover from one failure.

Scope the problem

Define contracts

Complete the diagram

Lead one deep dive

Prove reliability

Write

Propagate

Read

Trace the architecture in this order.

Enter and classify the request

Validate, then cross the commit boundary

Move replayable work off the request path

Serve reads from the right authority

Contain the dependency boundary

Deliver without changing the source of truth

Why each box exists—and what it must defend.

Name the database, shard key, indexes, and guarantees.

Pick one risk and explain the mechanism, alternative, and cost.

Clock authority

Game ownership

Spectators

Show detection, containment, recovery, and evidence.

Owner loss

Duplicate move

Client disconnect

Reference details

Core entities

External interfaces

Clock authority

Game ownership

Spectators

Owner loss

Duplicate move

Client disconnect

Can you redraw it from memory?