Implement Scalable Multi-Server Architecture with Gateway-Based Room Allocation

[anshggss]

Description

The current networking architecture supports only a single game server that accepts connections from all clients. This design does not scale and creates a single point of failure.

Implement a gateway-based architecture that dynamically allocates game rooms across multiple backend game servers.

Note: This is an umbrella issue. Subsequent issues related to the gateway, server manager, room allocation, server discovery, state synchronization, and cleanup will be created as smaller tasks and should be considered subsets of this issue.

Proposed Flow

Creating a Room

1. Client connects to the Gateway.
2. Client requests a new room.
3. Gateway generates a unique roomID.
4. Gateway requests an available game server from the Server Manager.
5. Server Manager selects an available server and returns its IP/address.
6. Gateway stores:

roomID -> serverIP

in a key-value store (e.g. Redis).

7. Gateway returns the roomID and serverIP to the client.
8. Client establishes a direct connection with the assigned game server.

Joining a Room

1. Client connects to the Gateway.
2. Client sends the roomID.
3. Gateway looks up the room in the key-value store.
4. Gateway returns the corresponding serverIP.
5. Client connects directly to the game server.

Cleanup

• Game servers periodically report their state (player count, capacity, etc.) to the Server Manager.
• When all players leave a room:
  • The game server notifies the Server Manager.
  • The Server Manager informs the Gateway (or updates shared state).
  • The Gateway removes the roomID -> serverIP mapping from the key-value store.
• The server is then available for future room allocations.

Benefits

• Horizontal scalability
• Better load distribution
• No single game server bottleneck
• Dynamic room allocation
• Automatic cleanup of unused rooms

High-Level Tasks

• Implement Gateway service.
• Generate unique room IDs.
• Implement Server Manager for tracking available servers.
• Implement server discovery and allocation.
• Store room-to-server mappings in a key-value store.
• Implement room lookup for joining players.
• Add server heartbeat/state reporting.
• Remove room mappings when rooms become empty.
• Update client connection flow to use the Gateway.

Future Improvements

• Least-loaded server selection
• Geographic routing
• Automatic server provisioning
• Health checks and failover
• Room migration during server failures