SysPadExamples › Multiplayer game backend

Multiplayer game backend

Self-managed game servers behind an NLB (not GameLift): ECS-on-EC2 session hosts, DynamoDB + DAX for player state, ElastiCache Memcached for the leaderboard, and Keyspaces for match history.

Low-latency L4 load balancing, a DAX cache in front of DynamoDB, and a multi-threaded Memcached tier sized independently of the DynamoDB read path.

Players Users NLB NLB Game Session Hosts ECS/EC2 Player State Cache DAX Player State DynamoDB Leaderboard Memcached Match History Keyspaces

How it works

NLB
Layer 4, because a game connection is a three-minute TCP session that has to stay pinned to one host, not an HTTP request any server can answer.
Game Session Hosts
ECS on EC2 rather than Fargate: the studio wants the instance type, the CPU pinning and the per-host tuning that managed compute takes away.
Player State Cache
Player state is read every tick and written rarely. DAX absorbs 92% of those reads at microsecond latency, which is what keeps the table behind it affordable.
Leaderboard
Everyone reads the same few hundred rows, so this is sized for read fan-out and nothing else. Memcached over Redis because there is no data structure worth keeping and nothing worth persisting.
Match History
Append-only and enormous: every match writes, almost nothing reads. A wide-column store handles that shape without the write amplification a relational schema would add.

Other reference architectures

Open this architecture in SysPad · All examples