Build a Global Gaming Backend System — System Design Interview Practice

Interview prompt

Design a globally distributed gaming backend for millions of concurrent players with low-latency matchmaking, authoritative game sessions, durable player progress, and regional failover.

• Separate authoritative per-match state from durable player inventory, ratings, rewards, matchmaking tickets, and telemetry.
• Place players and sessions near one another, keep game-loop work bounded, and isolate noisy regions and hot tournaments.
• Use a server-authoritative protocol with reconnect tokens, sequence numbers, lag handling, and cheat detection.
• Explain matchmaking fairness, party constraints, session migration, regional failure, and durable reward settlement.

Requirements and scale assumptions

• Authenticate players, create parties, enqueue matchmaking tickets, and return a match assignment with a region.
• Establish real-time game sessions, validate commands, broadcast snapshots, and support reconnect and spectate flows.
• Persist inventory, ratings, rewards, bans, and match outcomes with idempotent settlement and auditable events.
• Keep the game loop within a regional tick budget, target p95 command acknowledgement below 100 ms, and matchmaking below 5 seconds.
• Scale to millions of concurrent players by sharding sessions and queues by region, mode, and skill bucket.
• Do not lose settled rewards or bans; make reconnects, duplicate commands, and match results safe.
• Degrade by shedding non-critical telemetry and social reads while protecting authoritative session state.
• Support 10 million concurrent connections, 1 million active matches, and bursty launches by region.
• Partition by region, game mode, match ID, and player ID; isolate hot tournaments and large parties.
• Keep session memory bounded and retain commands, snapshots, settlement records, and telemetry for replay.

• Concurrent players: 10M peak — Drives connection gateways, session shards, regional capacity, and admission control.
• Command latency: p95 <=100ms — Regional acknowledgement target; the simulation tick budget is stricter than database latency.
• Durable boundary: Committed before async — The source of truth is the authoritative session shard and durable reward settlement record.
• Async boundary: At-least-once workers — Keep analytics, telemetry, recommendations, and non-critical social work off the game-loop path.

Key entities

• InteractioninteractionId, actorId, objectId, type, version, occurredAt

  Canonical global gaming backend system interaction with an idempotency key and ordering version.

• ConnectionSessionsessionId, userId, deviceId, roomKey, lastHeartbeat, status

  Ephemeral but observable global gaming backend system connection registration used for routing and presence.

• FanoutCursorstreamKey, shard, offset, consumerGroup, updatedAt

  Durable progress marker for global gaming backend system fan-out and replay.

• DeliveryReceiptinteractionId, recipientId, channel, attempt, status, deliveredAt

  Deduplicated global gaming backend system delivery state for reconnects, retries, or acknowledgements.

Data flow

1. 1. Accept and commit the interactionThe global gaming backend system gateway authenticates the actor, validates room or object membership, applies rate limits, and conditionally commits the interaction.
2. 2. Publish an ordered eventAn outbox emits the committed global gaming backend system transition with an event ID, partition key, sequence, and replay retention.
3. 3. Fan out by partitionConsumers route global gaming backend system events to connected recipients, durable inboxes, or notification channels without making the origin write wait for every recipient.
4. 4. Resume and reconcile connectionsClients reconnect with a cursor; the global gaming backend system service replays missed events, deduplicates delivery, and exposes stale or degraded state.
5. 5. Measure latency and recoverOperations tracks global gaming backend system publish-to-deliver latency, hot partitions, reconnect storms, dropped events, and consumer lag for replay or repair.

Deep dives and trade-offs

• Ordering, idempotency, and hot keysChoose a global gaming backend system partition key that preserves required order while distributing high-volume rooms, users, or objects. Use event IDs, inboxes, consumer offsets, and conditional state transitions for at-least-once delivery. Split or isolate hot partitions without changing the client-visible sequence contract.
• Reconnect and replay semanticsIssue resumable global gaming backend system cursors with an expiry and a clear snapshot-plus-delta fallback. Bound replay windows and rebuild from durable state when a cursor is too old. Expose version and freshness so a client can distinguish current, catching up, and degraded state.
• Backpressure and presenceKeep connection heartbeats and ephemeral presence separate from durable global gaming backend system interactions. Coalesce safe updates, shed low-value work, and protect critical events during reconnect storms. Measure end-to-end delivery, not only broker publish latency.
• Direct fan-out versus pull-based readsUse push for latency-sensitive global gaming backend system deltas and pull or replay for reconnect, history, and recovery. A push-only design loses state when clients disconnect and a pull-only design wastes latency and bandwidth.
• Per-recipient queues versus shared streamsUse shared partitioned streams with per-recipient cursors where fan-out is large, and isolate exceptional high-fanout objects. A queue per recipient becomes expensive and hard to inspect at large scale.
• Strong ordering versus availabilityGuarantee ordering only within the scope the product needs, such as a room, object, or conversation. Global ordering introduces a bottleneck and still does not solve duplicate delivery or reconnect recovery.