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

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

Wojciech Marusarz - May 29, 2020

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.

Just tap the screen to build a tower. Easy peasy

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.

Request with encoded results - easy to hack

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.

Request with game geometry

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.

How kafka works

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

System architecture

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.

About the author

Wojciech Marusarz

Wojciech Marusarz

Software Engineer

Linkedin profile Twitter Github profile

Wojciech enjoys working with small teams where the quality of the code and the project's direction are essential. In the long run, this allows him to have a broad understanding of the subject, develop personally and look for challenges. He deals with programming in Java and Kotlin. Additionally, Wojciech is interested in Big Data tools, making him a perfect candidate for various Data-Intensive Application implementations.

Tempted to work
on something
as creative?

That’s all we do.

join nexocode

This article is a part of

Zero Legacy
36 articles

Zero Legacy

What goes on behind the scenes in our engineering team? How do we solve large-scale technical challenges? How do we ensure our applications run smoothly? How do we perform testing and strive for clean code?

Follow our article series to get insight into our developers' current work and learn from their experience. Expect to see technical details, architecture discussions, reviews on libraries and tools we use, best practices on software quality, and maybe even some fail stories.

check it out

Zero Legacy

Insights from nexocode team just one click away

Sign up for our newsletter and don't miss out on the updates from our team on engineering and teal culture.


Thanks for joining the newsletter

Check your inbox for the confirmation email & enjoy the read!

This site uses cookies for analytical purposes.

Accept Privacy Policy

In the interests of your safety and to implement the principle of lawful, reliable and transparent processing of your personal data when using our services, we developed this document called the Privacy Policy. This document regulates the processing and protection of Users’ personal data in connection with their use of the Website and has been prepared by Nexocode.

To ensure the protection of Users' personal data, Nexocode applies appropriate organizational and technical solutions to prevent privacy breaches. Nexocode implements measures to ensure security at the level which ensures compliance with applicable Polish and European laws such as:

  1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (published in the Official Journal of the European Union L 119, p 1); Act of 10 May 2018 on personal data protection (published in the Journal of Laws of 2018, item 1000);
  2. Act of 18 July 2002 on providing services by electronic means;
  3. Telecommunications Law of 16 July 2004.

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet.

1. Definitions

  1. User – a person that uses the Website, i.e. a natural person with full legal capacity, a legal person, or an organizational unit which is not a legal person to which specific provisions grant legal capacity.
  2. Nexocode – NEXOCODE sp. z o.o. with its registered office in Kraków, ul. Wadowicka 7, 30-347 Kraków, entered into the Register of Entrepreneurs of the National Court Register kept by the District Court for Kraków-Śródmieście in Kraków, 11th Commercial Department of the National Court Register, under the KRS number: 0000686992, NIP: 6762533324.
  3. Website – website run by Nexocode, at the URL: whose content is available to authorized persons.
  4. Cookies – small files saved by the server on the User's computer, which the server can read when when the website is accessed from the computer.
  5. SSL protocol – a special standard for transmitting data on the Internet which unlike ordinary methods of data transmission encrypts data transmission.
  6. System log – the information that the User's computer transmits to the server which may contain various data (e.g. the user’s IP number), allowing to determine the approximate location where the connection came from.
  7. IP address – individual number which is usually assigned to every computer connected to the Internet. The IP number can be permanently associated with the computer (static) or assigned to a given connection (dynamic).
  8. GDPR – Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of individuals regarding the processing of personal data and onthe free transmission of such data, repealing Directive 95/46 / EC (General Data Protection Regulation).
  9. Personal data – information about an identified or identifiable natural person ("data subject"). An identifiable natural person is a person who can be directly or indirectly identified, in particular on the basis of identifiers such as name, identification number, location data, online identifiers or one or more specific factors determining the physical, physiological, genetic, mental, economic, cultural or social identity of a natural person.
  10. Processing – any operations performed on personal data, such as collecting, recording, storing, developing, modifying, sharing, and deleting, especially when performed in IT systems.

2. Cookies

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet. The Website, in accordance with art. 173 of the Telecommunications Act of 16 July 2004 of the Republic of Poland, uses Cookies, i.e. data, in particular text files, stored on the User's end device.
Cookies are used to:

  1. improve user experience and facilitate navigation on the site;
  2. help to identify returning Users who access the website using the device on which Cookies were saved;
  3. creating statistics which help to understand how the Users use websites, which allows to improve their structure and content;
  4. adjusting the content of the Website pages to specific User’s preferences and optimizing the websites website experience to the each User's individual needs.

Cookies usually contain the name of the website from which they originate, their storage time on the end device and a unique number. On our Website, we use the following types of Cookies:

  • "Session" – cookie files stored on the User's end device until the Uses logs out, leaves the website or turns off the web browser;
  • "Persistent" – cookie files stored on the User's end device for the time specified in the Cookie file parameters or until they are deleted by the User;
  • "Performance" – cookies used specifically for gathering data on how visitors use a website to measure the performance of a website;
  • "Strictly necessary" – essential for browsing the website and using its features, such as accessing secure areas of the site;
  • "Functional" – cookies enabling remembering the settings selected by the User and personalizing the User interface;
  • "First-party" – cookies stored by the Website;
  • "Third-party" – cookies derived from a website other than the Website;
  • "Facebook cookies" – You should read Facebook cookies policy:
  • "Other Google cookies" – Refer to Google cookie policy:

3. How System Logs work on the Website

User's activity on the Website, including the User’s Personal Data, is recorded in System Logs. The information collected in the Logs is processed primarily for purposes related to the provision of services, i.e. for the purposes of:

  • analytics – to improve the quality of services provided by us as part of the Website and adapt its functionalities to the needs of the Users. The legal basis for processing in this case is the legitimate interest of Nexocode consisting in analyzing Users' activities and their preferences;
  • fraud detection, identification and countering threats to stability and correct operation of the Website.

4. Cookie mechanism on the Website

Our site uses basic cookies that facilitate the use of its resources. Cookies contain useful information and are stored on the User's computer – our server can read them when connecting to this computer again. Most web browsers allow cookies to be stored on the User's end device by default. Each User can change their Cookie settings in the web browser settings menu: Google ChromeOpen the menu (click the three-dot icon in the upper right corner), Settings > Advanced. In the "Privacy and security" section, click the Content Settings button. In the "Cookies and site date" section you can change the following Cookie settings:

  • Deleting cookies,
  • Blocking cookies by default,
  • Default permission for cookies,
  • Saving Cookies and website data by default and clearing them when the browser is closed,
  • Specifying exceptions for Cookies for specific websites or domains

Internet Explorer 6.0 and 7.0
From the browser menu (upper right corner): Tools > Internet Options > Privacy, click the Sites button. Use the slider to set the desired level, confirm the change with the OK button.

Mozilla Firefox
browser menu: Tools > Options > Privacy and security. Activate the “Custom” field. From there, you can check a relevant field to decide whether or not to accept cookies.

Open the browser’s settings menu: Go to the Advanced section > Site Settings > Cookies and site data. From there, adjust the setting: Allow sites to save and read cookie data

In the Safari drop-down menu, select Preferences and click the Security icon.From there, select the desired security level in the "Accept cookies" area.

Disabling Cookies in your browser does not deprive you of access to the resources of the Website. Web browsers, by default, allow storing Cookies on the User's end device. Website Users can freely adjust cookie settings. The web browser allows you to delete cookies. It is also possible to automatically block cookies. Detailed information on this subject is provided in the help or documentation of the specific web browser used by the User. The User can decide not to receive Cookies by changing browser settings. However, disabling Cookies necessary for authentication, security or remembering User preferences may impact user experience, or even make the Website unusable.

5. Additional information

External links may be placed on the Website enabling Users to directly reach other website. Also, while using the Website, cookies may also be placed on the User’s device from other entities, in particular from third parties such as Google, in order to enable the use the functionalities of the Website integrated with these third parties. Each of such providers sets out the rules for the use of cookies in their privacy policy, so for security reasons we recommend that you read the privacy policy document before using these pages. We reserve the right to change this privacy policy at any time by publishing an updated version on our Website. After making the change, the privacy policy will be published on the page with a new date. For more information on the conditions of providing services, in particular the rules of using the Website, contracting, as well as the conditions of accessing content and using the Website, please refer to the the Website’s Terms and Conditions.

Nexocode Team


Want to be a part of our engineering team?

Join our teal organization and work on challenging projects.