Rooms, Instances, and Shards: How a Realtime Game Server Scales
How authoritative realtime servers isolate sessions into rooms and instances, what a shard is, the instance lifecycle from create to teardown, how reconnection works, and why scaling per session beats one big server.
The short version
- Realtime servers isolate each session into a room (one world), run it as an instance (one process), and split a large world into shards when needed.
- Instances are created, filled, run, drained, and torn down automatically as players come and go.
- Scaling per session beats one big server: load follows players, and one crash takes down one room, not the game.
Once your authoritative server works for one group of players, the next question is how it holds thousands of them at once. The answer is isolation: you do not run one giant world, you run many small ones.
Rooms, instances, and shards
| Term | What it is | Scope | Example |
|---|---|---|---|
| Room | One isolated logical world with its own authoritative state | One match, party, lobby, or session | A single 4-player co-op run |
| Instance | The running process that hosts one or more rooms | Compute that ticks the simulation | The server process holding that run |
| Shard | A slice of one large world split across instances | Region or zone of a big world | One area of a persistent map |
Most co-op and session games only need rooms and instances. Sharding matters when a single world is too big or too crowded for one process, which is an MMO-scale concern, not a co-op one.
The instance lifecycle
An authoritative instance moves through a predictable cycle:
- Create. A new room spins up, usually triggered by matchmaking or a player starting a session.
- Fill. Players are placed into the room. A matched group lands in a fresh instance, ready to play. See matchmaking vs server browsers for how players find a room.
- Run. The instance ticks the authoritative world, validates actions, and streams state to clients.
- Drain. As players leave, the room winds down and stops accepting joins.
- Teardown. The empty instance is released so its compute returns to the pool.
Done well, all of this is automatic. You should never be manually starting and stopping server processes.
Reconnection and resilience
Players drop. On a mobile network they drop a lot. A good realtime server keeps the room alive briefly so a player can rejoin the same world after a blip, and can hand a room between instances without losing state. This is the difference between "my connection hiccuped" and "the session is over", which is the chronic failure of listen-server co-op.
Why per-session scaling beats one big server
- Load follows players. Ten rooms or ten thousand, you only pay for instances that are actually running.
- Failure is contained. One instance crashing takes down one room, not the whole game.
- No capacity guessing. Instances are created on demand instead of pre-provisioned for a peak that may never come.
- No on-call scaling. A launch-day spike is the platform's problem, not your weekend.
Where Crux fits
Crux Realtime creates, fills, and tears down authoritative instances for you, plugs matchmaking straight into fresh rooms, and keeps state across reconnects, all without you provisioning or operating servers. You define the world; the platform handles how many copies of it are running and where. For the broader picture of how this sits next to auth and persistence, see multiplayer backend architecture.
Realtime game servers: the full series