Hypergaming architecture

Architecture of a middle-size Hypergaming cluster

Here is what each element shown in the above diagram is for:

• NGINX Load balancer: it's the HTTP layer between game clients and Hypergaming. It balances incoming http requests among the web nodes available in the Hypergaming cluster. Web nodes are connected to NGINX via permanent TCP sockets using Fast-CGI as the underlying protocol. The permanent TCP connection between NGINX and Hypergaming web nodes (as opposed to stateless http commonly used to connect web servers to http balancers) is ideal in this case as it helps to minimize request-to-response roundtrip time.
  If a web node ever goes down it is automatically excluded from the cluster and no request is sent to it until it is re-elected into the cluster by NGINX after having become available again.
• Hypergaming web nodes: web cluster made of Hypergaming instances. Hypergaming uses Redis to manage smaller data that frequently changes (sessions, active games rounds and configurations) and SSDB as a storage for accounting data, transactions and game play history.
• Redis: Redis is configured as a persistent store, this means that the data is stored both memory and on the file system (using fsync AOF strategy that guarantees no data loss even in case of power outage).
  In the big majority of the setups one single Redis instance is enough to handle all data, a Redis slave syncs the master in order to allow high-availability.
• SSDB: it is a blazing fast NOSQL database built on top of Google LevelDB whose performance is close to Redis (with the difference that with SSDB is not an in memory database as it write data directly on the file system). The SSDB cluster is made of N simmetrical nodes where each node is responsible for a specific data shard. The cluster follows a presharding strategy: this means that from the beginning of time each machine contains more than one nodes. When the cluster needs to scale (with SSDB this means that there is a need for more file system space) one ore more SSDB nodes from one machine can be moved to a new machine where more space is available. This enables the cluster to scale quickly without need of re-sharding data as the overall number of nodes and sharding configuration does not change.
  Each individual SSDB master node has its own slave which contains a replica of the data and resides on a different machine.
  Hypergaming uses a hashing strategy to determine on which SSDB node each data needs to be written/read.
• HAProxy Load Balancer: it is used to automatically promote Redis and SSDB slaves to master when the corresponding master node become unavailable. HAProxy is only used to implement high-availability of the SSDB and Redis nodes. It is not used as a load balancer because Hypergaming already knows how to route data to the right SSDB node.

To make the diagram less complex and easier to understand, additional elements such as monitoring agents have not been included. It is also important to underline that NGINX and HAProxy do not represent single-point-of-failure as in real setups they are also made redundant with active-passive nodes that can be switched at the DNS or BGP level.

Hypergaming server

Hypergaming is a multi-threaded C++ application built on top of FastCGI++ and Google V8 Javascript engine. Hypergaming core and modules (redis, ssdb, os, logging, http) are written in C++ while the game server code is entirely in Javascript. All functionality from the native modules is exported to Javascript.

Hypergaming is a completely stateless application: all information from active player sessions and current game rounds is stored in Redis and therefore it is centralized accross all the nodes of the cluster. This allows Hypergaming to scale efficiently as there is no need for data replication because all nodes are fully symmetric and have no state for what concerns the working of the game server.

The implementation of the game logic for specific game types is completely external to Hypergaming. Anytime a request from a game client is sent to the game server during a game round, Hypergaming invokes the underlying game engine as an external process. The state of game round is obtained from Redis and it is passed to the game engine together with the information of the incoming request. The game engine processes the input and generates the outcome which is passed back to Hypergaming as a result of the process execution. Finally Hypergaming updates the game round state in Redis and sends back the result to the game client.

Game engines are fully in charge of the outcome generation. Therefore the implementation of the game logic is completely decoupled from Hypergaming.
Hypergaming allows defining multiple game brands and game types, where each game type is associated to a specific game engine. Game engines can be written into any programming language.

Hypergaming comes with SLOT-IDE's game engine which is a highly efficient and widely used engine for slot games.
By incorporating the engine from SLOT-IDE Hypergaming is capable of supporting any slot game.
SLOT-IDE's engine features an internal Mersenne Twister RNG. The engine and RNG have been certified by the SIQ test lab.