ADR - Scaling the Core Game Server

[dudash]

ADR Context / Overview

Scaling the game server is a core architecture design needed to allow us to maintain a large player base. We need to identify the rules around how scaling works, what limitations we have, and where we expect to encounter any challenges or degradation of server capabilities. There will likely be multiple server side microservices that make up all the features of the game. But for this ADR we are limited to talking about services necessary to the gameplay state and physics management of the game.

Decision

The universe is split into an infinite hexagonal grid. The physics is processed by a core server. As a core server begins to near it's threshold it will scale out (aka +1 itself). This scale action triggers allows the game servers set to rebalance ownership of portions of the hex grid. Whichever server owns the a hex tile is responsible for physics and game state updates for that hex.

All communication is brokered via a separate component called the data bus. This removes the need for client <> direct connections. Instead we have client <> data bus ... and server(1)<>data bus ... server(2)<>databus... server(n)<>databus

Rationale

TBD @thoraxe @RoddieKieley

Status

Proposed

Consequences

• There might be some delay in rebalancing scale activities as hex tile ownership changes
• TBD more?

Authors

@thoraxe @RoddieKieley @dudash

[RoddieKieley]

@dudash I think while it is currently brokered, and was originally so, I think the core tenant is that it is a messaging bus at the application level. The move from the originally used JMS style messaging via OpenWire to be utilizing the ISO 19464:2014 standard AMQP 1.0 protocol should allow other messaging technologies to also be used as required, such as direct client to client, or routed via the respective Apache Qpid projects for example.