Game Server Development

Game Server Development Series — Part 3: Core Architecture

Gateway, rooms, zones, shards, matchmaking, persistence — the core architectural patterns of modern online games.

Leeting Yan 5 min read 916 words

A modern online game backend is not a single monolithic server.
It is a collection of specialized services working together to deliver real-time gameplay, persistent worlds, and social systems.

This chapter introduces the core architectural building blocks:

  • Gateway / Connection Layer
  • Room / Match Server
  • World Server
  • Matchmaking Service
  • Persistence Layer (DB, Cache)
  • Supporting Services (Chat, Social, Inventory, etc.)

By the end, you’ll understand how these pieces fit together into a working online game.

1. High-Level Architecture Overview

The modern multiplayer game backend is typically organized into a multi-service architecture, even if the underlying codebase is monolithic.

Here is a simplified map:

flowchart TB
    Client((Game Client))
    Gateway((Gateway / Load Balancer))
    RoomSrv[Room / Match Server]
    WorldSrv[World Server]
    MatchSrv[Matchmaking Service]
    AuthSrv[Authentication Service]
    DB[(SQL Database)]
    Cache[(Redis Cache)]
    MQ[(Message Queue)]
    Social[Social & Chat Service]

    Client --> Gateway

    Gateway --> AuthSrv
    Gateway --> MatchSrv
    Gateway --> RoomSrv
    Gateway --> WorldSrv
    Gateway --> Social

    AuthSrv --> DB
    RoomSrv --> Cache
    WorldSrv --> DB
    MatchSrv --> MQ

This structure supports real-time gameplay, persistent data, scalable rooms, and safe user management.

2. Gateway Layer — The Front Door

The gateway is the connection front-end for all players.

It handles:

  • TCP/UDP/WebSocket connections
  • Authentication (JWT, OAuth, custom tokens)
  • Load balancing across game servers
  • Region selection
  • DDoS protection
  • Packet routing
  • Rate limiting
  • API/Protocol version checks

The gateway is not responsible for game logic.
Instead, it forwards client messages to the correct game server.

2.1 Gateway Responsibilities Diagram

flowchart LR
    Client((Client))
    Gateway((Gateway Layer))
    Game((Game Logic Server))

    Client --> Gateway --> Game
    Game --> Gateway --> Client

Examples of gateway technologies:

  • NGINX
  • Envoy Proxy
  • Cloudflare Spectrum
  • Custom-built TCP/UDP dispatchers

3. Room / Match Server — The Real-Time Gameplay Engine

A Room Server (also called Match Server, Game Instance, or Session Server) is the engine that runs one match or one gameplay instance.

This is where:

  • Movement is simulated
  • Combat is resolved
  • Physics is applied
  • Abilities and effects trigger
  • Game rules execute
  • Real-time state is synced to players

Each room server typically handles one match or a small group of matches.

3.1 Room Server Lifecycle

  1. Matchmaking pairs players
  2. Server instance is allocated
  3. Players connect
  4. Gameplay simulation begins
  5. Match ends
  6. Results saved to DB
  7. Server resets or shuts down

3.2 Room Server Diagram

flowchart TB
    subgraph RoomServer["Room / Match Server"]
        S1[Simulation Loop]
        S2[Receive Inputs]
        S3[Update World]
        S4[Broadcast State]
        S5[Persist Results]
    end

    Clients((Players)) --> S2
    S4 --> Clients
    S5 --> DB[(Database)]

Room servers are generally stateful, running everything in memory for maximum speed.

4. World Server — Persistent Simulation

Unlike room servers, World Servers keep the game world alive 24/7.

Used in:

  • MMO
  • SLG (strategy base-building games)
  • Survival games
  • Open-world multiplayer

A world server may contain:

  • Global map simulation
  • Economy simulation
  • NPC/AI logic
  • Resource production
  • Long-running timers
  • Territorial control
  • Guild wars / events

4.1 Zoning & Sharding

Large worlds are divided into:

  • Zones
  • Shards
  • Regions
  • Cells / chunks

This allows large player bases to scale.

graph TD
    World((Game World)) --> Zone1
    World --> Zone2
    Zone1 --> CellA
    Zone1 --> CellB
    Zone2 --> CellC
    Zone2 --> CellD

World servers are typically built for consistency and persistence, not high tick-rates.

5. Matchmaking Service — Player Matching & Load Allocation

Matchmaking decides who plays with whom.

It handles:

  • Skill rating (ELO, Glicko, TrueSkill)
  • Region and latency sorting
  • Party matching
  • Role/position matching
  • Anti-smurf balancing
  • Server selection and room allocation

5.1 Matchmaking Flow

flowchart LR
    PlayerQueue((Player Queue))
    MatchMaker((Matchmaking Logic))
    Allocator((Server Allocator))
    Room((Room Server))

    PlayerQueue --> MatchMaker --> Allocator --> Room

Matchmaking operates at the “meta” level; it doesn’t simulate gameplay.

Often implemented as:

  • gRPC service
  • Microservice with Kafka/NATS
  • Part of a backend cluster

6. Persistence Layer — Saving Player & Game Data

Persistence includes:

  • SQL databases (PostgreSQL / MySQL)
  • Caches (Redis / Dragonfly)
  • NoSQL (MongoDB / Cassandra)
  • Object storage (S3 / OSS)
  • Message queues / event logs (Kafka / NATS)

6.1 What Gets Stored?

  • Accounts & authentication
  • Character data
  • Inventory & currency
  • Match history
  • Player MMR / ranking
  • Long-term world simulation
  • Social graph

6.2 DB Architecture Diagram

flowchart LR
    GameSrv((Game Server))
    Cache[(Redis Cache)]
    DB[(SQL Database)]
    Storage[(Object Storage)]

    GameSrv --> Cache
    Cache --> GameSrv

    GameSrv --> DB
    DB --> GameSrv

    GameSrv --> Storage

Good persistence design is essential for cheating prevention, performance, and long-term stability.

7. Supporting Services (Chat, Social, Guild, Economy)

Most games have multiple supporting backend systems:

  • Chat Service
  • Friends & Social Graph
  • Guild/Clan System
  • Economy Service
  • Inventory Service
  • Leaderboard Service
  • Analytics & Telemetry

Often built as microservices communicating via:

  • gRPC
  • HTTP
  • Redis
  • Kafka/NATS

This helps each system scale independently.

8. Putting It All Together — Full Architecture Diagram

Here is a complete architecture overview:

flowchart TB
    Client((Game Client))
    Gateway((Gateway Layer))
    MatchSrv[Matchmaking Service]
    Allocator[Room Allocator]
    RoomSrv[Room / Match Server]
    WorldSrv[World Server]
    AuthSrv[Authentication]
    SocialSrv[Social/Chat]
    InvSrv[Inventory/Economy]
    LeaderSrv[Leaderboard]
    DB[(SQL Database)]
    Cache[(Redis Cache)]
    MQ[(Message Queue)]

    Client --> Gateway

    Gateway --> AuthSrv
    Gateway --> MatchSrv
    Gateway --> SocialSrv
    Gateway --> InvSrv
    Gateway --> LeaderSrv

    MatchSrv --> Allocator --> RoomSrv
    RoomSrv --> Cache
    RoomSrv --> DB

    WorldSrv --> DB
    WorldSrv --> Cache

    SocialSrv --> MQ
    InvSrv --> DB
    LeaderSrv --> DB

This architecture supports:

  • Real-time room simulation
  • Persistent world simulation
  • Scalable matchmaking
  • Robust persistence
  • Social systems
  • Observability and analytics

9. Summary

In this chapter, you learned the core structure behind every modern online game:

  • Gateway Layer → routes players and handles connections
  • Room Server → real-time match simulation
  • World Server → persistent world and long-term simulation
  • Matchmaking → intelligent player pairing
  • Persistence Layer → storing progress and world data
  • Supporting Services → chat, social, economy, leaderboard

Understanding these components gives you a solid foundation for designing or building your own game backend.

Keep Reading

Follow the engineering thread

Get the next practical Birdor note, or browse the archive for related systems, tooling, and architecture work.

Join newsletter Browse articles