Cruxly › System design › Design Exercises

Multiplayer Game State Sync

hiding 100ms of network latency from a player who expects their keypress to happen now

Prompt: design the real-time state synchronization for a multiplayer action game — many players, each with 50-150ms of network latency to the server, all seeing a consistent, responsive view of a fast-moving shared world.

40 minutes first. This exercise is almost entirely about hiding physics — the speed of light isn't negotiable, so the design has to make its consequences invisible.

Applying the four moves: Scope — real-time shared world, many players, 50–150ms of latency each, consistent and responsive; matchmaking and persistence out. Estimate — tick rate × players × state per entity, which gives the bandwidth per client and decides how much state can be sent per tick at all. Sketch — an authoritative server simulating the world at a fixed tick rate, sending state snapshots or deltas to clients. Deep dive — hiding physics: client-side prediction so your own input feels instant, server reconciliation when the prediction was wrong, interpolation for other players, and lag compensation so a shot that hit on your screen counts on the server's.

Scope, and the number that makes this hard

In scope: real-time position/action sync for a fast-paced multiplayer game, latency compensation, basic cheat-resistance (server authority). Out of scope: matchmaking, the game's actual gameplay logic/rules engine, voice chat.

The authoritative-server model is the starting point, and it's a deliberate choice, not a default: the server holds the one true game state, and every client's view is a rendering of what the server most recently told it, delayed by network latency. The alternative — trusting each client's own reported position — is trivially exploitable (a modified client simply reports being wherever it wants), so server authority is the correctness/security baseline this whole design is built on, at the direct cost of every action needing a round trip to take effect authoritatively.

50-150ms of round-trip latency is not a tuning parameter to optimize away — it's a physical constant (the speed of light over real-world fiber routes) that the design must hide the effects of, not eliminate. This reframing — "latency compensation," not "latency reduction" — is the entire point of the exercise.

Client-side prediction and server reconciliation

Prediction makes the local player feel instant; reconciliation quietly corrects the prediction once the authoritative answer arrives, without the player perceiving the round trip at all in the common case.

Client-side prediction: the local player's own actions are applied immediately on their own machine, before the server has even received the input, let alone responded — this is what makes a keypress feel instant despite the round trip. The input is simultaneously sent to the server, which processes it against the authoritative state after the network delay.

Server reconciliation handles the case where the server's authoritative result disagrees with what the client predicted — a collision the client's prediction didn't account for, another player's action that interacted with this one, or simple prediction drift. When the client receives the server's authoritative position for an input it already predicted, it compares the two; if they match, nothing visible happens. If they differ, the client snaps (or smoothly interpolates) to the authoritative position, then replays every input sent after the one the server just acknowledged — because those later inputs were predicted against a now-corrected base state and need to be re-simulated from it, not discarded. Getting this replay step right is what separates smooth correction from visible rubber-banding.

Entity interpolation for other players

Prediction only applies to the local player's own actions — a player has no input to predict for anyone else. Other players' positions are rendered via entity interpolation: rather than snapping to each new position update the instant it arrives (which looks jerky, since updates arrive in discrete bursts, not continuously), the client deliberately renders other players slightly in the past — buffering a short window (around 100ms) of position updates and smoothly interpolating between the two most recent ones. This trades a small amount of added visual delay for eliminating jitter, and is a completely different technique from prediction because it's solving a different problem: prediction hides latency for actions that need to feel instant (your own), interpolation hides update-arrival gaps for state you're only observing (everyone else's).

Lag compensation for hit detection is the sharpest version of this tradeoff. When player A fires at player B, A's client shows B at B's position from A's perspective right now — which, because of latency, is actually where B was some milliseconds ago from the server's point of view. Server-side lag compensation rewinds the server's own history of where B was, to the moment A's client says it fired, and checks the hit against that rewound position — this is what makes "I clearly hit them" register as a hit despite both players seeing a slightly different, laggy version of the world. The real cost: this can produce the frustrating "shot around a corner" feeling for the player being hit, who — from their own perspective — had already reached cover by the time the hit registers. Naming this specific, well-known player-facing tradeoff is what shows real depth here, not just naming the rewind mechanism.

Failure modes and the honest edges

Cheating via a modified client is only fully prevented by the parts of the simulation the server actually verifies. Client-side prediction displays an optimistic local position, but if the server doesn't independently validate that a claimed movement was physically possible (speed hacking: a modified client simply claims to have moved farther than the game's rules allow), the "authoritative server" model is authoritative in name only. Server-side sanity checks on every input (maximum plausible speed, cooldown enforcement) are what actually make the server authority claim true, not just the architecture diagram.

Very high latency or packet loss degrades prediction accuracy non-linearly — small latency produces small, rarely-visible corrections; high latency (300ms+) or lossy connections produce large, frequent, visible corrections, because more of the client's predicted state has diverged from the server's authoritative state by the time reconciliation arrives. There's a real ceiling past which prediction stops being able to hide latency convincingly, worth naming rather than implying the technique scales to arbitrary latency.

State synchronization bandwidth grows with player count in a shared space — broadcasting every player's position to every other player is O(n²) in the worst case for n players in visual range of each other. Interest management (only sending state updates for entities within a player's relevant visual/gameplay range) is the standard fix, the same "only send what the recipient actually needs" principle as this track's activity-feed fan-out exercise, applied to spatial relevance instead of social-graph relevance.

How to say it in the interview

"The one number that shapes this entire design is round-trip latency, because a player pressing a key and waiting 100ms to see it happen feels broken, so the real problem is producing an instant local response that is later reconciled against a server that has not seen that input yet."

Checklist

Chose authoritative-server as a deliberate security/correctness baseline, not a default
Reframed the problem as hiding latency's effects rather than reducing latency itself
Used client-side prediction so the local player's own actions render instantly, before server confirmation
Replayed inputs sent after the server-acknowledged one during reconciliation, rather than discarding or ignoring them
Distinguished entity interpolation for other players from prediction for the local player as solving different problems
Explained server-side lag compensation as rewinding server history to the shooter's perceived moment of firing
Named the 'shot around a corner' player-facing cost of lag compensation explicitly
Required server-side validation of claimed movement, not just an authoritative-server architecture diagram
Named a real ceiling where prediction stops convincingly hiding latency at high latency or packet loss
Used interest management to avoid O(n squared) state broadcast growth in a shared space

Practice this interactively