How about some Kafka for a fast and fraud-safe game backend? Yes, please!

Creating a game can bring some fun into your daily routine, but it is also very challenging. Just have a look at a blocks game that we’ve created – a one-click game in which the player builds a tower. The higher the tower, the better.

In the basic version, it is a single-player browser game written in JavaScript, but we’ve created a PWA application to be able to run the game both in a browser and on a smartphone. We also wanted to introduce a competitive element by allowing many players to play the game and compare their results.

To achieve that, we had to prepare a back-end application that would collect all the results, persist them and display the names of the winners on the scoreboard. Here’s how we did it.

Let’s build some blocks – the easy way

The main goal for the player is to win. To select the player who built the highest tower, we can send HTTP POST requests after each game, including tower height and game duration. However, since it is very easy to modify http requests, the data needs to be encoded.

Unfortunately, the system is prone to hacking, as users have easy access to the javascript code, can encode any result and send it to the server as their own results.

It’s a better idea to send the whole game geometry in a http request, or better so, to send each block as a separate http request – along with the block’s coordinates and a timestamp – of course, also as encoded values. Having both the final result and the coordinates of each block, we can build a tower of blocks on the server side, and validate if each block is within the borders of a block below, and if a tower height matches the recorded final result.

Ok, but will it be fast and reliable? Will it handle a high traffic load? Will it be fraud-resistant? Let’s have a closer look.

Traffic load

When creating the game, we envisioned there would be about 200 players playing the game concurrently. That would be about 500 blocks sent to the server side at a peak. We also have to be prepared to handle an increased traffic load generated by users attempting a DDoS attack. Obviously, had the game become unresponsive, it would have damaged our reputation.

Fraud detection

In case of a DDoS attack, we have to handle invalid blocks, and filter them later. We have to detect if game geometry is valid, but we also have to validate timestamps of each block to detect if time-gaps between them are not too small or too big. When each block is sent independently, it requires a lot of read/write database operations or persisting every pending game in memory, which would not be the best choice if we wanted to use a load balancer.

Would a game based on standard HTTP requests handled by Spring MVC be able to fulfill our requirements? Unfortunately not. We needed something special, which is why we used Apache Kafka.

Let’s build some blocks – the right way

To implement a fast and reliable version of the game – one that could handle high traffic load and perform computations for fraud detection, we decided to use architecture based on Apache Kafka. Why?

About Kafka

Kafka is a data bus with a persistence layer, installed as an independent service. It is designed for high availability and high efficiency. Applications communicating with Kafka can be data producers, data consumers, or both. Producers can send binary data to Kafka, which stores them on hard-drive for a specified period of time, and any data consumer which subscribes to the data, can read them.

What’s the benefit? You can read all incoming data, persist it in Kafka almost immediately – and the server won’t slow down. The data is available before the application is ready to make further computations including fraud detection.

To distinguish different types of data stored in Kafka, incoming messages are assigned to topics, i.e. logical partitions on a Kafka Broker. For the purpose of the game, each block is assigned to the blocks topic. We also need to persist the current game progress, and completed games for the sake of fraud detection.

Implementation details

We decided to divide the whole game processing into three independent parts

• Handling incoming requests We created a data bus that handles each block. Three types of blocks are sent: Game Start, Next Level, Game End. Each block is sent to the Kafka blocks topic. This operation is very fast. Server returns a response to the UI application immediately.
• Tracking game progress Separate Kafka Stream Topology builds current game progress. Background process reads each block from the blocks topic, groups them by gameGuid and creates current game progress. It reads the Game Start block, reads each Next Level block, and if the Game End block is detected, the whole game is saved in the Kafka games topic.
• Fraud detection Separate Kafka Streams Topology validates game and persists best results. Background process reads completed games from the games topic, validates game results including blocks coordinates, timestamp and achieved result. If the game is valid, it persists in MongoDB – ready to be displayed on the dashboard.

That’s how it looks - clear and easy to understand

And that’s it. We did it. Using Kafka allowed us not to worry about high traffic load, data loss or application slowdown. Immediate response allowed to keep user satisfaction level high, and all data processing could be performed in background. Best results were displayed on the dashboard.

If you want to play the game, you can find it here: Nexocode Blocks

Valuable lesson

Creating the game was fun for us, but it also required some effort. It allowed us to create an application that is resistant to high traffic load. It allowed us to take advantage of Kafka and Kafka Streams. It also required some infrastructure with load balancing and services installed on dockers. But at the end of the day it brought us a lot of satisfaction and, most importantly, we achieved our goal.