Design a multiplayer typing game: system design interview question

How the interviewer opens it

“Design an online multiplayer typing game. Players race to type the same passage and can see how the others are doing.”

The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.

What to clarify first

game rules
matchmaking
scale
traffic and read:write mix
latency
timing and ranking
consistency versus availability
disconnects
durability
trust and scope

The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.

Scope of a strong answer

Core requirements

Match players into a race with a shared passage and countdown
Accept typing input and show live progress for every participant
Determine finishing order and save final results
Let a briefly disconnected player rejoin an ongoing race

Usually out of scope

Chat, spectators, and tournaments
Building account authentication
Perfect detection of bots or external typing assistance
Seamless continuation after losing the server that owns a race

What interviewers probe

Authoritative progress, timing, and the limits of validation: A client can claim any progress or timestamp, and it already knows the target passage. The server can enforce game rules and consistent ranking, but validating correct text does not prove that a human typed it.
Room ownership and bounded real-time fanout: The system has many small independent groups, not one global broadcast channel. Forwarding every keystroke creates unnecessary traffic, while a slow socket or overloaded room server can delay every participant's view and distort server-observed finish times.
Reconnects, duplicate input, and one durable terminal outcome: A reconnect can leave two live sockets and uncertain input delivery. Separately, the owner can fail between calculating a winner, saving the result, and notifying clients. These cases must not create extra progress or contradictory outcomes.

Common mistakes

Treating the game as CRUD over a shared progress table, with database polling for every update.
Trusting client-reported completion time, progress percentage, or WPM.
Confusing text validation with proof that a human typed the text.
Broadcasting every edit without calculating room fanout or handling slow consumers.
Omitting input sequence numbers and connection replacement rules during reconnect.
Designing seamless distributed failover before asking whether an interrupted race may be aborted.

The bar by level

Senior (L5/E5): Quantifies fanout, chooses serialized room ownership, defines authoritative timing and finish rules, and handles backpressure. Walks through reconnect deduplication, replacement of stale connections, and persistence before final notification. Separates basic validation from bot detection.
Staff (L6+/E6+): Makes the availability and fairness contract explicit, including network bias and acceptable race loss. Defines ownership fencing and terminal-state races, plans capacity and draining around short-lived rooms, and can explain exactly what stronger failover or spectator requirements would cost without overbuilding v1.

Scope of a strong answer

Core requirements

Match players into a race with a shared passage and countdown
Accept typing input and show live progress for every participant
Determine finishing order and save final results
Let a briefly disconnected player rejoin an ongoing race

Usually out of scope

Chat, spectators, and tournaments
Building account authentication
Perfect detection of bots or external typing assistance
Seamless continuation after losing the server that owns a race

What interviewers probe

Authoritative progress, timing, and the limits of validation

A client can claim any progress or timestamp, and it already knows the target passage. The server can enforce game rules and consistent ranking, but validating correct text does not prove that a human typed it.

Room ownership and bounded real-time fanout

The system has many small independent groups, not one global broadcast channel. Forwarding every keystroke creates unnecessary traffic, while a slow socket or overloaded room server can delay every participant's view and distort server-observed finish times.

Reconnects, duplicate input, and one durable terminal outcome

A reconnect can leave two live sockets and uncertain input delivery. Separately, the owner can fail between calculating a winner, saving the result, and notifying clients. These cases must not create extra progress or contradictory outcomes.

Common mistakes

Treating the game as CRUD over a shared progress table, with database polling for every update.

Trusting client-reported completion time, progress percentage, or WPM.

Confusing text validation with proof that a human typed the text.

Broadcasting every edit without calculating room fanout or handling slow consumers.

Omitting input sequence numbers and connection replacement rules during reconnect.

Designing seamless distributed failover before asking whether an interrupted race may be aborted.

The bar by level

Senior (L5/E5)

Quantifies fanout, chooses serialized room ownership, defines authoritative timing and finish rules, and handles backpressure. Walks through reconnect deduplication, replacement of stale connections, and persistence before final notification. Separates basic validation from bot detection.

Staff (L6+/E6+)

Makes the availability and fairness contract explicit, including network bias and acceptable race loss. Defines ownership fencing and terminal-state races, plans capacity and draining around short-lived rooms, and can explain exactly what stronger failover or spectator requirements would cost without overbuilding v1.