The Technology That Keeps Millions of Players Connected in Real Time

A multiplayer session that feels instantaneous is doing something the underlying network cannot actually deliver. Light takes time to cross an ocean, packets get lost, and the server has no way to know what a player will do next. The sensation of shared, immediate presence is manufactured, and the engineering behind that manufacture is some of the most interesting infrastructure work in consumer software.

The problem statement is unforgiving. Thousands of participants, each sending inputs several times per second, each expecting a consistent world state, across connections ranging from fibre to congested mobile. Latency, consistency, and scale all have to be solved at once, and the solutions to each tend to make the others harder.

Different Genres, Radically Different Requirements

Before any of the mechanisms, it is worth establishing that the requirements are not uniform. A competitive shooter needs sub-fifty-millisecond response. A strategy title tolerates several hundred. A turn-based design barely cares at all.

This matters because the engineering effort should match what the game actually needs. Someone browsing a catalogue of online games is looking across genres whose networking demands differ by two orders of magnitude, even where the titles look superficially similar in scale.

People who play online board games are running on infrastructure that would be entirely inadequate for a shooter, and it makes no difference to the experience, because the design never asked the network for something it could not provide. A great deal of complexity in this field exists to serve the demanding end, and applying it where it is not needed is expensive without being better.

The Transport Layer

 

Everything starts with how the connection is held open. Traditional web requests are transactional: ask, receive, close. That model is useless for a persistent shared world, because the server needs to push updates the client never requested.

The WebSocket protocol was standardised precisely to solve this. The standard covers holding it open as a full-duplex channel over one TCP connection, replacing the polling workarounds earlier real-time applications relied on. Once the handshake completes, either side can send at any time, and per-message overhead drops to a few bytes rather than a full set of HTTP headers.

For genuinely latency-critical work, UDP-based transports remain preferred, because TCP's guarantee of ordered delivery becomes a liability. If one packet is lost, TCP holds everything behind it until the retransmission arrives, which is exactly wrong for position updates where newer data supersedes old. A dropped position packet does not need recovering. The next one is already more accurate.

Where the Server Lives

Physical distance sets a floor on latency that no amount of code removes. A round trip between continents costs well over a hundred milliseconds regardless of how efficient the software is.

The answer is to stop having one server. Edge platforms terminate connections at whichever data centre is closest to each player and coordinate state between those points. Platform documentation on terminating nearby describes the general shape: connections held at the edge, with a stateful coordination layer handling the per-room logic any non-trivial real-time feature requires.

This is why regional matchmaking exists. Grouping players by geography is not a social feature, it is an admission that the physics cannot be argued with.

Predicting the Future to Hide the Present

The most important trick in real-time gaming is that the client does not wait.

When a player presses forward, their machine moves the character immediately and simultaneously tells the server. This is client-side prediction. The player sees instant response because their own device made the decision locally rather than waiting for confirmation.

The server then processes that input authoritatively and returns its verdict. Usually the two agree and nothing visible happens. When they disagree, because another player acted first or inputs arrived out of order, the client reconciles: it snaps to the server's version and replays any inputs since. Done well this is imperceptible. Done badly it produces the rubber-banding anyone who has played on a poor connection will recognise instantly.

For other players' characters, the client interpolates between known positions rather than predicting, deliberately rendering them slightly in the past so there are two known points to move between. Every player is therefore seeing a subtly different version of the world, and the design goal is only that nobody can tell.

Authority and Trust

None of the above works without a clear answer to who decides what actually happened.

The server is authoritative in any serious multiplayer design, because clients are controlled by people who may want to cheat. A client reporting its own position, hit registration, or resource count is an invitation. The server simulates, validates every input against what is physically possible, and rejects the rest.

This is the same trust problem that appears in any distributed system lacking a central arbiter. Arguments for removing the arbiter reach the opposite conclusion from game engineering: multiplayer titles deliberately retain a central authority precisely because the alternative makes cheating trivial in an environment where participants have strong incentives to lie.

Scaling to Many

A single server instance handles a bounded number of concurrent participants. Beyond that, the architecture has to shard.

Interest management is the main lever. A player only needs updates about entities they can perceive, so the server maintains a spatial index and sends each client a filtered view. Someone across the map generates no traffic for you at all. This turns a problem that would otherwise scale with the square of the player count into something closer to linear.

Larger worlds partition space across instances, with handoff logic for players crossing boundaries. The apparent scale of a large persistent world is usually the product of aggressive filtering rather than genuine simultaneous simulation of everything in it.

The Illusion Holds Because Everyone Cooperates

What makes all of this work is that client, server, and network are jointly maintaining a fiction. The client pretends it knows the future. The server pretends the client's guess was right whenever it plausibly could have been. The rendering pipeline pretends other players are where they were a moment ago.

None of the participants are seeing the same world state at the same instant, and none of them can tell. That coordinated approximation, rather than any single protocol or platform, is the actual technology keeping millions of players connected.