Game server engineering fundamentals

It means one process owns the only copy of game state that counts, and every other copy is a cache of it. Clients send input; they do not send outcomes. If a client reports that it is standing on a rooftop, the server checks whether the movement it received could have got it there and overwrites the client if not. The word matters because it defines a boundary of trust rather than a topology: you can run an authoritative simulation inside one of the players' own processes and it is still authoritative, and you can run a dedicated server that naively accepts positions from clients and it is not.

A listen server is one player's client also running the authoritative simulation, so that machine both plays and arbitrates. It costs nothing to host and it makes the host structurally advantaged: the host has zero network latency to the authority, sees state first, and can be modified with no server left to disagree. A dedicated server runs the simulation with no local player, usually in a data centre chosen for latency, so every participant is equally distant and the binary is under your control. Free-to-play and competitive titles pay for dedicated servers because the fairness and anti-cheat arguments are worth more than the hosting bill.

The reason is not raw overhead, it is what happens to a lost packet.

UDP, snapshots every 50ms, snapshot for t=200 is lost
  t=150 arrives -> render
  t=200 lost    -> skip it, nothing to do
  t=250 arrives -> render, world is current again

TCP, same loss
  t=150 arrives -> delivered
  t=200 lost    -> retransmit pending
  t=250 arrives -> HELD in the kernel, cannot be delivered out of order
  t=200 retransmit arrives -> now t=200 and t=250 both delivered
     the client receives a snapshot it no longer wants, late

The TCP column is head-of-line blocking. Because TCP guarantees ordered delivery, a snapshot that arrives on time is withheld until an older one it does not care about has been recovered, so a single loss delays everything behind it by at least a round trip. For state that is superseded every 50ms this is precisely wrong: the retransmitted snapshot is worthless by the time it lands, and waiting for it made the useful one late too.

UDP lets the application make that decision per message. State updates are sent unreliably and stale ones are simply dropped, while the small minority of messages that genuinely must arrive — a chat line, a match-start command, an entity spawn — get an application-level acknowledgement scheme layered on top. That is why almost every shipped game protocol is "UDP plus a reliability channel we wrote ourselves" rather than either protocol as it comes.

There is a second, smaller reason worth mentioning: TCP's congestion control interprets loss as a signal to slow down, which for a fixed-rate simulation stream means the game stops updating exactly when the network is already struggling.

A session is one bounded instance of play with a fixed roster: a match, a raid instance, a lobby. It has a lifecycle — created, filled, started, finished, torn down — and its state is discarded at the end, which is why session servers can be treated as disposable capacity. A shard is a long-lived world with persistent characters, where a player's identity and inventory live in one shard and cannot be trivially moved to another. The distinction drives the whole operational model: sessions scale by allocating more of them, whereas a shard scales only by being split or by having its population capped.

It removes server hosting cost entirely and can lower latency, because two players in the same city talk directly instead of both routing through a distant data centre. What it leaks is addressing and trust. Every participant learns every other participant's IP address, which is a real harassment and denial-of-service vector in competitive play. More fundamentally, with no neutral arbiter you either accept whatever peers assert or you make each peer verify the others, and both roads end at a modified client winning arguments. Peer-to-peer suits co-operative and casual play; it does not suit anything with a ranked ladder.

The three are routinely used interchangeably in conversation and mean different things.

tick      one step of the authoritative simulation, fixed duration
frame     one image the client draws, variable duration
snapshot  a network message describing state at the end of some tick

server at 60Hz tick, 20Hz send:
  ticks   1  2  3  4  5  6  7  8  9 ...    every 16.7ms
  sends      ^        ^        ^           every 50ms, one per 3 ticks

client at 144fps:
  frames  drawn every ~7ms, interpolating between the last two snapshots

Read the middle row first. The server simulated nine ticks and sent three snapshots, which means six of its ticks were never described to anyone. That is normal and intentional: simulation fidelity and bandwidth are separate budgets, and hit detection or physics stability may need a rate that the wire cannot afford.

The client row shows why the counts do not need to agree either. At 144fps the client draws roughly seven frames between snapshots, all of them invented by interpolating, and none of them corresponds to a tick at all. So "we run at 60 ticks" tells you about simulation accuracy, "we send at 20" tells you about bandwidth and about how much smoothing the client must do, and "it runs at 144fps" tells you nothing about either.

It is deciding, per client, which entities are worth sending. In a shared world with thousands of entities, sending everything to everyone is both unaffordable and a cheat vector, so the server maintains a relevance set per connection — typically by spatial partitioning into grids or cells, plus visibility and team rules — and only replicates entities inside it. The cost is that the relevance set has to be recomputed as players move, and its edges are visible: an entity entering relevance has no history to interpolate from, so it must be spawned rather than smoothly introduced, which is what causes things to pop into existence at the horizon.

A relay accepts packets from each participant and forwards them to the others without simulating anything. It solves two problems that have nothing to do with authority. First, connectivity: two players behind restrictive network address translation may be unable to establish a direct path, and a publicly addressable relay always can. Second, address privacy, since peers only ever see the relay's address. The cost is an extra hop of latency and the bandwidth bill for every packet in both directions, so relays are usually a fallback attempted only after direct connection fails.

Everything in a server's budget is a division by the tick rate, which is why the number is argued about so much.

tick rate   budget per tick   at 20 ticks/s of CPU work per tick...
---------   ---------------   ------------------------------------
20 Hz       50.0 ms           comfortable
30 Hz       33.3 ms           comfortable
60 Hz       16.7 ms           the whole tick must fit in 16.7ms
128 Hz       7.8 ms           7.8ms for physics, AI, replication, I/O

worst-case wait before your input is even looked at:
  20 Hz  ->  up to 50 ms      before any network latency
  60 Hz  ->  up to 16.7 ms

The first table is the cost side. Raising the tick rate divides the compute budget per tick while leaving the work per tick roughly unchanged, so it directly reduces how many players or entities one machine can host — the hosting bill scales with it almost linearly.

The second is the benefit side, and it is smaller than players assume. A higher tick rate reduces the quantisation delay before input is sampled and improves the temporal resolution of collision and hit detection, so a fast-moving projectile is tested at more points along its path. Both are real, and both are bounded by a fraction of a tick.

The thing to say out loud is that tick rate cannot buy back network latency. A player on a 90ms round trip gains a few milliseconds from a doubled tick rate and still has 90ms of round trip. Teams that raise the tick rate hoping to fix "the game feels unresponsive" usually find the complaint was about prediction, correction or interpolation, and pay double for hosting without moving the metric.

Because a variable step makes results depend on frame timing, and every technique in this discipline depends on them not doing so. With a fixed step, tick 400 given the same inputs produces the same state on every machine and on every replay, which is what makes lockstep, rollback, replay files and server-side rewind possible at all. A variable step also destabilises numerical integration: collision responses and constrained joints behave differently at 4ms and 40ms, so a machine having a bad frame gets different physics rather than slower physics. The fixed step is the foundation the rest of the stack is built on.

The order of operations inside a tick is itself an interview question, because two of the steps are commonly put in the wrong place.

flowchart TD
  A["Drain input packets<br/>into per-player buffers"] --> B["Validate inputs<br/>against limits"]
  B --> C["Advance simulation<br/>one fixed step"]
  C --> D["Resolve combat<br/>with rewound state"]
  D --> E["Build per-client<br/>relevance sets"]
  E --> F["Serialise deltas<br/>and send"]

The first thing to notice is that input draining happens once, at the top, rather than continuously. Packets arrive whenever they arrive, but they are only consumed at a tick boundary, which is where the quantisation delay in the previous item comes from. Anything that arrived after the drain waits for the next tick.

The second is that validation sits before simulation, not after. If a client claims a movement of impossible magnitude, the correct response is to clamp or discard it before it enters the simulation, because once an illegal value has been integrated into world state you are unwinding rather than rejecting.

The third is that relevance is computed after the simulation advances and separately per client, which is why the replication stage rather than the simulation stage is what usually dominates the tick as player counts rise. Simulation cost grows with the number of entities; replication cost grows with entities multiplied by observers.

Tick rate is how often the server advances its simulation; send rate is how often it transmits state to a given client. They are separate budgets because they are limited by different resources — tick rate by CPU, send rate by bandwidth and by the client's ability to absorb updates. A server may tick at 60Hz and send at 20Hz, which means each snapshot skips two of its own ticks. Send rate is also legitimately per-client and per-entity: a distant vehicle can be described five times a second while the player next to you is described twenty.

You have two bad options and must pick one deliberately. Either the server keeps the fixed step and falls behind wall-clock time, so the whole match runs in slow motion and drifts further behind as long as the overrun persists, or it drops ticks to catch up, which means simulation steps that never happened and physics that behaves as though objects teleported. Most servers do a bounded version of the second with a cap on how many steps they will catch up in one go. Either way the real answer is that the tick budget is a hard latency requirement, so overrun has to be treated as an outage-class problem rather than as slow performance.

Because the two serve different masters. Rendering wants to run as fast as the display allows, varies with scene complexity, and can afford to be approximate. Simulation must be a fixed step for the determinism reasons above and gains nothing from running at monitor refresh. So the client simulates at its fixed rate and the renderer draws whatever interpolated state is appropriate for the current instant, blending between the last two simulated states. The visible consequence of getting this wrong is stutter that no amount of frame rate fixes, because the smoothness problem is in the sampling rather than in the drawing.

The standard structure is an accumulator, and it is worth being able to write because the two failure modes are both in it.

accumulator += frameDeltaTime
steps = 0
while accumulator >= STEP and steps < MAX_STEPS:
    simulate(STEP)
    accumulator -= STEP
    steps += 1

if steps == MAX_STEPS:
    accumulator = 0          # give up on catching up

alpha = accumulator / STEP   # leftover time, 0..1
render(interpolate(previousState, currentState, alpha))

The MAX_STEPS guard is the first thing to look at. Without it, a machine that cannot simulate a step within a step's worth of real time accumulates more debt each frame, so the loop runs more steps, takes longer, and accumulates still more — the death spiral where one slow frame becomes a hang. The cap converts that into a game that runs slow, which is recoverable.

The alpha line is the second. The accumulator almost never divides evenly, so at render time the simulation is between two states rather than on one. Ignoring the remainder and drawing the latest simulated state produces a subtle judder, because the interval between the states you draw does not match the interval between the frames you draw them on. Keeping the previous state and interpolating by the remainder is what makes a fixed-step simulation look smooth at an arbitrary frame rate.

The third detail, easy to miss, is that input must be sampled before the loop and held constant across all steps within a frame, or a single frame with three steps will read the same button press three times at different points and behave differently from a frame with one.

Almost every multiplayer design question resolves into a choice between these, and the axes that decide it are not the ones candidates usually reach for.

model                  on the wire        bandwidth vs     input       cheat
                                          entity count     latency     resistance
---------------------  -----------------  ---------------  ----------  ----------
deterministic lockstep inputs only        flat             worst peer  weak
authoritative server   state snapshots    linear           hidden by   strong
                                                           prediction
peer-to-peer with      inputs plus        flat-ish         low         very weak
distributed authority  ownership claims

The column that decides real designs is the third, not the first. Lockstep's bandwidth is flat in entity count because entities are derived rather than described, which is why real-time strategy with thousands of units uses it and a four-player shooter with a dozen entities does not. Entity count, not player count, is the axis.

The fourth column explains the other half of the industry. Under lockstep every client holds the complete world state, so fog of war is a rendering decision and a modified client can simply choose to draw it all. An authoritative server can decline to transmit what a client should not know, which is a structural guarantee no client-side measure matches. That single fact keeps competitive shooters and persistent worlds on servers regardless of the bandwidth arithmetic.

The last column is where lockstep's real bill arrives. Because a turn cannot advance until every participant's input for it has arrived, the input delay everyone experiences is set by the worst link in the match, and it applies to your own input on your own screen. Prediction cannot help, because predicting would break the determinism the model depends on.

Determinism means the same starting state plus the same ordered inputs yields bit-identical results on every machine and every run. It is not a property an engine has; it is a discipline maintained across the whole simulation. The usual culprits are floating-point results that differ with compiler flags or instruction selection, iteration over containers whose order depends on memory addresses or hash values, uninitialised memory being read, any use of wall-clock time or an unseeded random source, and anything that depends on frame rate. Each is invisible until two machines disagree, at which point the match is unplayable rather than merely degraded.

Because floating-point addition is not associative, so summing the same set of values in a different order gives a different result, and the last bit of difference compounds over thousands of ticks into a visibly different world. Order changes for mundane reasons: a different container iteration order, a parallel reduction, a compiler contracting a multiply and an add into a single fused operation on one target and not another. Nothing here is a bug in the usual sense, which is why teams either constrain the build tightly, or move the simulation to fixed-point arithmetic where the result is exactly specified.

It is the tripwire that turns a silent divergence into an immediate, localised failure. Each machine hashes its simulation state at the end of every tick — or every few ticks — and the hashes are compared, so the first tick where two machines disagree is reported at once rather than discovered minutes later when a unit dies on one screen and survives on another. Hash only authoritative simulation state: positions, health, timers, the random number generator's own state. Including anything presentational, such as animation or particle state, produces false divergences and trains the team to ignore the alarm.

The idea is that a client already knows almost everything, so send only what changed relative to a state you can prove it has.

server keeps a per-client history of sent snapshots

tick 300: send full state,           tagged 300, baseline = none
tick 303: client acks 300
tick 303: send diff vs 300,          tagged 303, baseline = 300
tick 306: no ack yet from client
tick 306: send diff vs 300 again,    tagged 306, baseline = 300
tick 309: client acks 306
tick 309: send diff vs 306,          tagged 309, baseline = 306

The pattern to read is the repeated baseline at tick 306. The server may only diff against a snapshot the client has acknowledged, so while acknowledgements are outstanding the baseline stays put and each successive delta grows, because more has changed since that older reference. Packet loss therefore inflates bandwidth at exactly the moment bandwidth is scarce, and a client on a lossy link costs the server more than a healthy one.

The second thing the trace shows is that each snapshot must carry the identifier of the baseline it was built against, not just its own. A client receiving a delta tagged as being against 306 when it only holds 300 cannot apply it, and must say so rather than guess — the recovery is to request a full state and start again.

The third is the memory cost. Per-client snapshot history is the price of this scheme, and it scales with players multiplied by history depth, which for a large server is a real allocation rather than a footnote. That bound on history is also what sets how much loss a connection can absorb before a full resend becomes unavoidable.

A baseline is the specific past snapshot a delta is expressed relative to. If the client no longer holds it — because it never arrived, or because it has been evicted from a bounded history — the delta is undecodable and cannot be partially applied without corrupting state. The only correct recovery is for the client to say which snapshot it does hold, or to request a full uncompressed state, which is a large packet at an inconvenient moment. This is why joining a match mid-flight and recovering from a bad network burst use the same code path.

Replicate events when the receiver can derive the consequence and when missing one is not survivable — a door opened, a match started, an item picked up. Replicate state when the value is continuous and self-correcting, such as position or health, because a lost update is repaired by the next one. The trap is using events for continuous values: every event then becomes reliable traffic that must be retransmitted, and a client that misses one drifts permanently because nothing later contradicts it. State updates are idempotent in the sense that the newest one is always the truth, which is what makes them safe to send unreliably.

Spawn and destroy are the reliable minority inside an otherwise unreliable stream, because there is no later update that repairs a missed one — a client that never learned an entity exists will never be told about it again, and one that missed a destroy keeps a ghost forever. So they go on a reliable channel with acknowledgement and retransmission, while the entity's per-tick position goes unreliably. The other necessity is a stable identifier that is never reused within a match, or a delayed state update for a destroyed entity will resurrect it, or worse, be applied to whatever now holds that identifier.

The client applies your input to its own copy of the simulation immediately, without waiting for the server to confirm it, so your character moves on the frame you pressed the key rather than a round trip later. This is what makes a server-authoritative game feel responsive at all. It is only possible for entities whose input you own, and only if the client runs the same movement code as the server, which is why that code is usually shared rather than reimplemented. Prediction always implies a reconciliation step, because sooner or later the client's guess and the server's truth will differ.

Reconciliation is a specific bookkeeping arrangement, and it is the input sequence numbers that do the work.

client sends inputs, each numbered
  seq 41 42 43 44 45 46 47   (all applied locally on arrival)

server snapshot arrives: "state after processing your input 44"

client:
  1. discard its own inputs up to and including 44
  2. snap its predicted state to the server's state for 44
  3. re-apply inputs 45, 46, 47 on top of that state
  4. render the result

Step 3 is the one candidates leave out, and without it prediction unravels. If the client simply adopts the server's state for input 44, it has thrown away three inputs it already showed the player, so the character visibly jumps backwards by however far it moved in that window — on a 100ms link, roughly the distance a sprinting player covers in 100ms, every single snapshot.

The bookkeeping requirement follows from that: the client must retain every input it has sent but not yet seen acknowledged, together with the predicted state, so it can replay them. The buffer's depth is therefore proportional to latency, and a client on a very bad link is replaying a long tail of inputs every snapshot.

The last detail is what to do when step 2 finds a real disagreement rather than a rounding difference. Snapping is correct for your own character, because you are about to replay your inputs on top and the visible result is usually within a few centimetres. It is wrong for remote characters, which is where smoothing belongs. Mixing those two up produces either a rubber-banding local player or remote players who lag their own corrections.

It holds your local input for a fixed number of frames before applying it, so that the remote player's input for the same frame has time to arrive and both machines simulate that frame with complete information. Nothing is ever predicted and nothing is ever corrected, so the picture is always coherent. The cost is paid on your own controls, uniformly, for the whole match. It remains the right answer where a visual correction is unacceptable or where the simulation cannot be cheaply saved and restored, and it is frequently combined with rollback: a couple of frames of delay absorb the common case so that rollbacks become rarer and shallower.

Rollback is easiest to follow as an exchange over time rather than as a description of state.

sequenceDiagram
  participant L as Local sim
  participant B as State buffer
  participant N as Network
  L->>B: save state at frame 300
  L->>L: predict remote input, advance 301 302 303
  N->>L: real remote input for 300 differs
  L->>B: restore state at frame 300
  L->>L: re-simulate 300 301 302 303
  L->>L: present frame 303

The first thing to read is the ordering. Every step after the restore happens inside the same display frame as the packet's arrival, so a rollback of four frames means running the simulation step five times in one frame. Your per-step cost must therefore fit in a fraction of the frame budget, which is why rollback is native to two-character fighting games and awkward in anything with an open world.

The second is what is predicted. It is the remote player's input, not their position, and the prediction is almost always "they are still holding what they held last frame" — a very good guess, because human inputs are held rather than tapped. Your own input is never predicted, which is precisely why your own character always responds instantly and never gets corrected.

The third is subtler: frames 301 to 303 are re-simulated with predictions again, because their real inputs have not arrived either. A rollback corrects the past only as far forward as the packet reached; it does not resolve the future. The same frame may therefore be simulated several times over its life, and the version the player sees is whichever was current when it was presented.

That is also where the artefact lives. The error surfaces on the character you are not controlling, appearing as a shimmer on a good link and as teleporting on a bad one. It is a deliberate choice to spend visual coherence, and only the remote player's, in exchange for local input that never waits.

It is projecting an entity forward from its last reported position, velocity and orientation using a motion model both ends share. The half that gets omitted is that the sender runs the same model: it continuously computes what receivers currently believe, compares that against the truth, and transmits an update only when the divergence exceeds a threshold. An entity moving in a straight line at constant speed therefore costs almost nothing on the wire. The technique came out of large-scale distributed simulation as a bandwidth-reduction scheme, and the smoothing that clients get from it is a side effect rather than the purpose.

Because rendering them in the present would require inventing their positions, and rendering them slightly in the past does not. The client buffers incoming snapshots and draws remote entities as of a fixed interval ago — one snapshot interval plus a jitter margin — so there are always two genuine snapshots bracketing the render time and the drawn position is a real blend of two states the server reported. The cost is deliberate additional latency on everything you see other players do, and that added delay has to be accounted for by the server when it validates a shot, or hit registration is systematically biased.

Convergence keeps the difference between where an entity was being drawn and where it has just been corrected to as a separate quantity, then drives that error to zero over a short window so the entity walks to the truth over several frames instead of jumping. Snapping is honest and looks broken, particularly when it happens several times a second on a jittery link. The price of convergence is that for the length of the window you are knowingly drawing a position that is neither the old estimate nor the new truth, which is fine for a distant running player and unacceptable for a projectile, where the position is the gameplay.

The standard answer is a sequence number plus an acknowledgement bitfield in every packet header, which gives you loss information without a separate acknowledgement packet.

every packet carries:
  seq       this packet's number                 e.g. 1207
  ack       highest sequence received from peer  e.g. 1189
  ackBits   32-bit mask, bit n set if
            packet ack-n was also received       e.g. ...11011

peer reads that as: 1189 received, 1188 received, 1187 missing,
                    1186 received, 1185 received, ...

The first thing this buys is that acknowledgement is free. Because game traffic flows continuously in both directions, every outgoing packet carries the receipt for the last thirty-odd incoming ones, so a single reply covers a whole window and one lost reply is repaired by the next packet rather than needing a timer.

The second is that the sender learns which specific packets were lost, and can then decide per message what to do about it. State updates are simply forgotten. Reliable messages are re-queued into the next outgoing packet rather than retransmitted as a copy of the old one, so they travel with current data instead of stale data. That last distinction is the whole reason not to use TCP: retransmitting the message is right, retransmitting the packet is not.

The third is that ordering becomes a per-channel decision rather than a global one. Chat wants ordered delivery; an entity spawn wants reliable but unordered; positions want neither. TCP gives one policy to everything, and the cost of that single policy is head-of-line blocking on the traffic that would rather be dropped.

It is the server rewinding its recent history to reconstruct the world as the shooter's client displayed it, then testing the shot against that reconstruction rather than against the present. Without it, hitting a moving target requires leading it by your own latency, which players cannot do consistently. With it, the shooter is rewarded for aiming at what they saw. The payer is the target: they can be hit after having moved, including after having reached cover, because the shot is being resolved against a world in which they had not yet moved. Lag compensation does not remove the unfairness of latency, it relocates it onto the person being shot.

The arithmetic matters more than the concept, because it is what makes the "shot behind cover" complaint inevitable rather than a bug.

shooter: ping 80ms, interpolation delay 100ms, server tick 60Hz

t = 0     server simulates tick 500, target at position P1
t = 40    snapshot for 500 reaches shooter
t = 140   shooter's interpolation delay expires, target drawn at P1
          shooter fires here, tagging the command with tick 500
t = 180   fire command reaches server, now simulating tick ~511
          target has since moved to P2, possibly behind cover

server rewinds its history to tick 500, restores the target to P1,
tests the shot there, and awards the hit

The number that governs everything is 180ms, and it is the sum of two different delays. Half of it is the network round trip, which is the part everyone accounts for. The other half is the shooter's own interpolation buffer, which is a client-side rendering decision the server must nonetheless know about, because the shooter was looking at 100ms-old information when they pulled the trigger. A server that rewinds only by measured ping under-rewinds by the interpolation delay and quietly denies hits that the shooter saw connect.

The second thing the timeline shows is why the target's experience is unavoidable. Between tick 500 and the shot being resolved, eleven ticks of real simulation happened. The target genuinely moved, genuinely reached cover, and is then killed by a shot resolved against a world in which they had not. No amount of tick rate closes that gap, because it is made of latency, not of resolution.

The design lever is the rewind limit. Servers cap how far back they will reconstruct, typically to a few hundred milliseconds, because beyond that the target's experience becomes indefensible and the window becomes a cheat surface for anyone who can inflate their reported latency. Naming that cap is the part of this answer that reads as production experience.

It is the target's side of lag compensation: they reached cover on their own screen and were then killed, which feels like the server ignoring the geometry. It is unavoidable because two clients cannot both be looking at the same instant. The shooter fired at what they were shown, which was old; the target moved in a present the shooter could not yet see. Whichever way you resolve it, someone is disadvantaged by latency that is not their fault, and the choice you are actually making is which of the two experiences to protect. Being able to say that plainly, rather than describing it as a bug, is the answer.

Packets do not arrive at even intervals even when none are lost, so a client that consumed each snapshot on arrival would produce uneven motion. A jitter buffer holds arriving snapshots for a short, deliberately chosen interval so that the client always has a queued snapshot to work towards, converting variance in arrival time into a constant added delay. The tuning is a direct trade: a deeper buffer absorbs worse jitter and makes everything you see about other players later, while a shallow one is more responsive and starves — falling back to extrapolation — whenever the network hiccups.

Latency is consistent and learnable: a player on a stable 120ms link adapts their timing and can play well, because everything is uniformly late. Loss is not learnable, because it is intermittent, so the client is smooth and then briefly guessing, and the correction when real data returns is a snap. This is why average ping is a poor health metric on its own and why jitter and loss belong beside it. It is also why a connection with 60ms and two per cent loss frequently plays worse than a clean 120ms one.

Because prediction distributes the error unevenly and asymmetrically. Under prediction and reconciliation the local player is always correct and remote players are the ones who get rewritten, so each participant experiences a game in which everyone else is slightly unreliable. Under symmetric input delay everybody's controls are equally late and nobody's picture is ever wrong, so the disadvantage is visible, uniform and attributable. Genres where precise mutual timing is the skill — fighting games, rhythm games — often prefer that honesty, whereas genres built on individual reaction speed prefer prediction and accept the artefacts.

It should degrade in stages rather than either freezing or guessing indefinitely. First it extrapolates from the last known state, because a short gap is best covered by assuming motion continues. As the gap lengthens the extrapolation becomes untrustworthy, so it should decay entities towards a rest state instead of flinging them across the map — a player projected forward for a full second at sprint speed ends up somewhere absurd, and the correction is worse than the stall. In parallel it should surface the condition in the interface, because a player who knows their connection dropped forgives what a player who thinks the game is broken does not.

Because the simulation is the state, and it changes sixty times a second. A stateless web request can be served by any instance because the truth lives in a database, but a match's authoritative world cannot be round-tripped to storage per tick and cannot be reconstructed from scratch on another instance without pausing play. That single fact reshapes the whole operational model: no load balancer distributing requests across a pool, no rolling restart in the middle of a session, and no autoscaling on average CPU. Instead you get session affinity by construction, capacity planned in whole sessions, and drain-before-terminate as the only safe deployment strategy.

Allocation is a matching problem with placement constraints, not a load-balancing problem, which is why it needs its own component.

flowchart TD
  A["Matchmaker forms<br/>a roster"] --> B["Allocator picks<br/>a region"]
  B --> C["Find a ready<br/>idle server"]
  C -->|"none free"| D["Scale the fleet<br/>and wait"]
  C -->|"found"| E["Mark it allocated<br/>and hand out address"]
  E --> F["Players connect<br/>match runs"]
  F --> G["Match ends<br/>process recycled"]

The branch out of the third node is the reason a fleet is not an autoscaling group. A new instance takes far longer to become playable than a match takes to form — image pull, process start, level load — so scaling on demand is far too slow to serve a waiting roster. Fleets are therefore kept warm, holding a buffer of idle, fully loaded processes sized against forecast demand, and the interesting operational metric is how many are ready rather than how busy the ones in use are.

The recycle step is the second thing to notice. Because a session's state is discarded at the end, the process is usually terminated and replaced rather than reused, which guarantees no state leaks between matches and makes deployment straightforward: stop handing new matches to the old version and let the fleet turn over as sessions finish.

The third point is that placement is decided by latency to the roster, not by which region has spare capacity. A cheap idle server in the wrong region is worthless, so capacity has to be planned per region and per time of day, following the sun as each population's evening arrives.

The arithmetic is the reason large shared worlds look the way they do.

assume: 20 snapshots/s, 20 bytes of delta per described entity

per client downstream = entities described x 20 bytes x 20/s

  10 entities   ->   4 KB/s      trivial
  60 entities   ->  24 KB/s      fine
 500 entities   -> 200 KB/s      a problem
2000 entities   -> 800 KB/s      not shippable

server upstream = per-client rate x player count
  100 players x 24 KB/s = 2.4 MB/s from one process

The first line to read is the last one. Per-client cost is linear in entities, but the server's own egress is the product of entities and observers, so it grows quadratically as a shared world gets busier. That product, not the simulation, is what usually caps a server's population.

The second is that the fix cannot come from compression alone. Halving the bytes per entity buys one doubling of the entity count; the shape of the curve does not change. What changes the shape is reducing the number of entities each client is told about at all, which is why interest management is not an optimisation but a structural requirement.

The third is that the update rate is a per-entity decision and one of the cheapest levers available. Describing distant entities five times a second instead of twenty cuts their contribution by three quarters at a cost players cannot see, because a figure at two hundred metres does not need twenty positions a second to look right. Tiering by distance and importance is the standard shape: full rate for what you can interact with, reduced rate for what you can only see.

Sharding duplicates the world: several independent copies each with their own population and their own persistent characters, which caps concurrency per copy and means two players must choose the same shard to meet. Meshing partitions one world across processes by region, so a single continuous world is simulated by many servers and players cross between them. Meshing preserves the fiction of one world at the cost of the hardest problem in the discipline — handing an entity from one authority to another mid-motion, and dealing with interactions that straddle the boundary. Sharding is boring and works, which is why most persistent worlds still do it.

Because latency is the product in a way it is not for most software. Twenty milliseconds of additional round trip is perceptible in a shooter and unfixable by any technique on this page, whereas twenty milliseconds added to a web request is invisible. That forces capacity into many regions close to populations rather than a few cheap ones, and it means utilisation is structurally poor: each region needs enough warm capacity for its own peak, and those peaks are at different hours. The cost of multiplayer hosting is mostly the cost of that geographic duplication rather than of the compute itself.

Very little of it survives by default, because the authoritative state was in memory. Making a match recoverable requires periodic checkpointing of simulation state somewhere durable, clients able to reconnect to a new address without a full relaunch, and an idempotent way to reapply whatever progression was awarded so a rollback to the last checkpoint does not duplicate rewards. Most session-based games decline all of this and instead compensate players for an aborted match, because the engineering cost is large and the frequency is low. Persistent worlds cannot decline it, which is why they checkpoint character state constantly and treat the world simulation as the disposable part.

Three quantities that conflict: match quality, wait time and server placement. Tightening skill tolerance improves quality and lengthens queues; widening geographic tolerance shortens queues and worsens everyone's latency. Real matchmakers therefore relax constraints as a ticket ages rather than searching for an optimum, and the interesting engineering is in that relaxation curve and in the concurrency of forming lobbies from a shared pool of tickets. The answer that shows understanding names the population as the binding constraint: a mode with a small concurrent population cannot have good matches and short queues, and no algorithm changes that.

Because the client has to be trusted for exactly one thing — the player's input — and the whole discipline is about drawing that line precisely. Input is the only thing the client is the authority on, and even then only within bounds: a movement vector is accepted but clamped to a legal magnitude, a fire command is accepted but checked against the weapon's cooldown. Everything else the client might send is derived state and must be recomputed rather than believed. The failure mode is not a naive server that accepts positions; it is a server that recomputes most things and accepts one derived value because it was convenient.

The distinction that matters is between what the client is allowed to assert and what the server must compute for itself.

client may assert            server must derive
---------------------------  --------------------------------------
movement intent, clamped     resulting position, after collision
look direction               what is visible from there
"I fired at tick 500"        whether the weapon could fire then
"I used the item"            whether the item was in the inventory
"I opened the door"          whether the player was in range
sequence number of input     the tick it is applied to, bounded

The right-hand column is where the value of the answer is. Position is the canonical example: taking a client's position is the classic teleport hack, so the server integrates the movement itself and applies collision. But the same argument applies to every row, and the rows people forget are the last two. Range checks on interactions are routinely omitted because the client already checked before showing the prompt, which is precisely why they are worth checking.

The sequence-number row is the subtle one. A client that controls which tick its input is attributed to controls how far the server rewinds for it, which is a lag-compensation exploit rather than a movement one. The claimed tick must be bounded against the server's own view of that client's latency, and inputs claiming to be older than the rewind window must be rejected rather than clamped.

The general shape to state out loud is that the server accepts intents and produces outcomes, and every place where an outcome arrives from the client instead is a vulnerability regardless of how harmless the value looks.

It is a client submitting more movement than time has passed for, either by sending inputs faster than real time or by inflating the time delta attached to each. The server catches it by owning the clock: it applies at most one input per simulation tick per player and integrates using its own fixed step rather than any duration the client supplied. Accumulated drift between a player's submitted input count and elapsed server ticks is then a direct signal, since a legitimate client's count tracks the tick count within a small tolerance. The general principle is that time is server state, exactly like position.

Because a wallhack does not falsify anything — it draws information the client legitimately received. If the server has told a client where an enemy is so it can be rendered when it becomes visible, then the client possesses that position and no amount of process protection stops it being drawn through a wall. The only structural fix is to stop sending it, which means server-side visibility culling: computing what each client can actually see and omitting the rest. That is expensive, imperfect at the margins, and in tension with smooth rendering, because an entity you were not told about must pop in rather than be interpolated into view.

Human aim has characteristic dynamics: a rapid gross movement, an overshoot, a correction, and continuous small jitter while tracking. Programmatic aim tends to be too good in specific, measurable ways — angular changes faster than a hand can produce, snapping onto a target the instant it becomes visible, tracking with less error than a human sustains, and target acquisition that ignores which target is the visible threat. Detection is therefore behavioural and statistical rather than a signature match, which means it deals in probabilities and needs a review path, because a false positive on a genuinely excellent player is expensive in a way a missed detection is not.

It protects the traffic in transit: an observer on the network cannot read state, learn positions, or inject packets, and it prevents casual proxy-based tampering. It does nothing about the endpoint. The client must decrypt in order to render, so anything the client is sent is available to a modified client, which is why encryption is not an answer to wallhacks or aimbots. The honest summary is that transport security addresses attackers between the players, while cheating is an attacker at one end of the connection, and only the authority boundary addresses that.

Because it makes the server act on a client's claim about time. A rewind is performed on behalf of a player according to how far behind they are believed to be, so a player who can inflate that belief gets a larger rewind and can hit targets that had moved further. Deliberate latency manipulation — briefly delaying or withholding packets — is the exploit that follows, and it is difficult to distinguish from a genuinely poor connection. The mitigations are all bounds rather than detection: cap the rewind window, derive latency from the server's own measurements rather than from anything the client asserts, and reject inputs claiming an age outside the window.

They want a sequence of decisions with their costs named, not a list of techniques. The expected spine is: the server is authoritative, clients predict their own movement and reconcile against snapshots, remote entities are interpolated from buffered snapshots, hit detection rewinds on the server, and the transport is UDP with a small reliable channel. Each of those has a follow-up attached to it, and the round is largely made of those follow-ups. Candidates who name the five decisions and the cost of each are doing well; candidates who list techniques without saying which problem each answers are pattern matching.

Almost every quantitative question in this round is one of a handful of divisions, and doing them aloud is most of the credit.

frame or tick duration     1000 / rate
  60 Hz  -> 16.7 ms       144 Hz -> 6.9 ms      20 Hz -> 50 ms

frames of latency          round trip / frame duration
  80 ms at 60 Hz -> ~5 frames

per-client bandwidth       entities x bytes x send rate
  60 x 20 x 20 = 24 KB/s

server egress              per-client x players
  24 KB/s x 100 = 2.4 MB/s

distance covered during latency
  6 m/s sprint x 0.1 s = 0.6 m

The first two lines are the ones that come up most, because they convert between the units players and engineers use. A complaint expressed in milliseconds becomes a design constraint expressed in frames, and five frames of input delay is a statement a fighting-game developer immediately understands where eighty milliseconds is not.

The bandwidth pair matters because it is where a design is falsified. If your answer implies a hundred and fifty players each being told about a hundred and fifty others, the arithmetic says megabytes per second per client and the design is finished. Doing that multiplication unprompted, and then reaching for interest management or a reduced update rate as the fix, is a strong signal.

The last line is the one candidates never volunteer and interviewers like most. Converting latency into metres is what makes lag compensation concrete: at a sprinting pace, a hundred milliseconds is most of a body width, which is exactly why hit registration disputes feel the way they do and why the rewind cannot simply be skipped.

Talk about a mechanism you have implemented at any scale rather than a title you have worked on. A toy project with a fixed-step simulation, client prediction and a reconciliation buffer demonstrates the thing being tested, and the honest framing — that it was two clients on a local network with artificial latency injected — reads better than vague association with a large project. What fails is describing techniques exclusively in the abstract, because the follow-ups in this discipline go immediately to specifics: what did you save, how deep was the buffer, what did the correction look like on screen.

Proposing an architecture whose bandwidth or tick budget does not survive one multiplication, and not noticing. The second fastest is answering a latency question with a bigger number: raising the tick rate to fix responsiveness, or raising the send rate to fix stutter, when the cause was prediction or interpolation. The third is treating the client as trustworthy for one convenient value. All three are failures of the same kind, which is reasoning about mechanisms without reasoning about their cost, and it is the specific thing this round exists to test.

Something small with an unmistakable mechanism in it. A two-client demo with a fixed-step simulation, a configurable artificial latency and loss injector, client prediction with reconciliation, and a toggle between interpolation and extrapolation so the difference is visible on screen. That is a weekend or two of work and it lets you answer nearly every question on this sheet from experience rather than from reading. The latency injector is the part that turns it from a demo into evidence, because being able to say what the correction looked like at three hundred milliseconds is a thing only implementation teaches.

At the client's snapshot buffer and at the arrival timing, not at the network averages. The likely cause is jitter: packets averaging well but arriving unevenly, so the interpolation buffer intermittently runs dry and the client falls back to extrapolating, then snaps when real data returns. That reads as stutter rather than as lag. The checks are whether inter-arrival intervals are uniform, whether the buffer is being starved, and whether the buffer's depth is tuned for the worst arrival variance rather than the mean.

The second candidate is a mismatch between rates: a send rate that does not divide evenly into the client's simulation rate, or a client interpolating towards the newest snapshot rather than towards a fixed render time, so the interval it interpolates over changes from frame to frame. The third is convergence tuning, where corrections are applied over a window short enough to be perceived as a jerk.

A weak answer proposes raising the tick rate or the send rate. That spends money to shrink each hitch without addressing why the buffer starves, and it shows the techniques were learned as a list rather than as a pipeline with one place where smoothness is produced.