First, let's talk about how the Coinracer game setup is implemented.
We have the Coinracer game client, which is a downloadable component that contains the main files of the game and is distributed through our third-party providers (game launchers, distribution platforms, etc.).
Next, we have the server build, which is split into three categories as can be seen below.
Coinracer's game servers are instance based. This means they are activated once all the criteria for a game lobby are created. Once a lobby is created, the instance uses only the assets assigned to that game instance (player cars, player nicknames, race type, race track assets, etc.). However there is a 24/7 live instance that handles all the requests for new lobbies, microtransactions, and asset updates. After a race is completed, the instance is powered off and the players are shifted back to the 24/7 live instance.
This flow ensures that if for some reason a race instance didn't execute properly, the player's in-game assets are not impacted in any way or form, while also enabling our infrastructure provider to scale both vertically and horizontally based on service demand (amount of players racing at the same time).
Our database server is hosted on Azure Cloud Services and uses the PlayFab server configuration which specializes in gaming data management. The database servers are using the following backup plan:
24 Hour: temporary (available for 24 hours only, afterward it gets overwritten with the new 24-hour back-up).
Weekly: temporary (available for one week only, afterward it gets overwritten with the new weekly back-up).
Monthly: permanent (this back-up is automatically uploaded to our dedicated datacenter, self-hosted server in Romania).
Our middleware layer is comprised of multiple microservices that are linked through the Azure Cloud API gateway. This list includes the following.
Custom Swap Microservice: handles and processes conversion initiated through the in-game swap feature and is integrated with various third-party transaction processors, acting as a validator for all player's transactions (in-game, on-chain, or off-chain).
Revenue Share Microservice: handles the revenue share model by interacting with the dedicated RPC nodes for each blockchain and aggregating the data received from the on-chain revenue share contracts.
Cybersecurity Monitor Microservice: ensures that all other microservices and their inherent API calls are not compromised (due to security reasons we will not disclose how they are doing this 😄).
