Developing affiliate marketing software for the Quints platform

There are many gambling establishments and iGaming businesses on the Internet, ranging from casinos to sports betting. Every day, thousands of players pass through them, placing bets and performing other activities. Players do not come to these casinos and betting services on their own, but through intermediaries who distribute links, usually through banners on the Internet.

If a player registers at a casino through a third person or company, then a certain percentage of the player's spending is paid out to the intermediary. Quints was created to provide affiliate tracking solutions for gaming companies to manage their entire array of information on the players and the people who invited them.

There are three main participants in Quints’ online gambling affiliate statistic services:

• Customers - online casino brokers, betting agents, or even online stores.
• Players - the individuals who play in online casinos, place bets with bookmakers, or make online purchases.
• Affiliates - the intermediaries who bring the players to the customers, mainly through ads. Customers hire various affiliates to refer players to them, and the affiliates receive a reward.

However, in order to pay rewards to affiliates, customers need to know how many players each of the affiliates brought in and how much these players ultimately spent. As an online gambling software provider, this is where Quints comes in.

Quints is a layer between the customers and affiliates. It is a system for collecting stats on affiliate marketing and working with this data, using various graphs, reports, etc. Both customers and affiliates use Quints, so it has two different types of client accounts.

Getting started

Quints generates a special link for the affiliate that they insert into their ads. When a player clicks on the link, they are directed first to Quints. The system captures this data and redirects it further to the customer.

When the affiliate marketing platform receives an array of data, specific formulas are used to calculate affiliate payments for each player. So, Quints is essentially a kind of aggregator or calculator of game statistics.

Quints’ owners approached Evrone with an already developed, two-year old product for affiliate reporting and customer management. The application had quite a lot of legacy, and about 70-80% of the functionality already existed. However, during our joint work on the project, much of it has been finalized and improved. Now, our team is working on optimization and implementation of new features, to turn the project into something brilliant.

The task

Quints’ main challenge was that it was not one project, but many different projects, with their own characteristics, for each client. The core of the project was developed, but when a new customer connected, a separate fork was made for them. And from this fork, a separate application was deployed for that particular client.

Simply put, for 10 clients, we had 10 forks from the core, which essentially turned into 10 different projects. And, in the future, each of the clients wanted the ability to improve or modify their individual projects themselves. As a result, instead of one project that needed to be developed and supported, we received 10 projects, and that number was expected to grow as Quints continued to onboard new customers.

Deploying new features was very difficult, due to the fact that all the projects were slightly different from one another. And, when deploying, these specific differences had to be taken into account. The outlook for such an architecture seemed overwhelming since Quints needed to attract new clients, but each new client meant even more work.

The solution

When we joined the project, the first thing we started to do was to change the approach to the architecture. We began to move (and are still moving) towards a unified project. We wanted to make sure that all clients have the same code, and the differences are only in the configurations and settings. This would allow us to develop just one project, not as many projects as there are clients.

During the life of the project, we also came to the conclusion that it lacked a layer between the customer and the application itself. So, we created a service that allowed the clients to send us raw data, which we, using the DWH service, collected and prepared in the required format for Quints to work. It allowed the clients not to spend time on aggregation on their side. This is a highload service that exchanges a fairly large amount of data, and now it works perfectly.

Together with the Quints team, we drew up documentation on the work of the project. Initially, the application had no documentation at all. We are also trying to bring all the tests on the project to the correct state. In general, the project is undergoing intensive refactoring of the functionality.

Tech stack

The project is not monolithic and is divided into frontend and backend parts. The backend is written in Ruby on Rails, with the frontend in Angular.js. The frontend and backend are separate applications that communicate over the API provided by the backend.

Infrastructure and tech stack:

• Infrastructure: Kuber, DO, Prometheus (self-hosted), ELK (self-hosted), Amazon, CloudFlare
• Frontend: SPA (single page application) on Angular.js 
• Backend: Ruby 2.3, Rails 4.2, Postgres 9.x, ClickHouse, Sidekiq Enterprise
• Additional: Gitlab (self-hosted), Jira, Confluence, Sentry (self-hosted), Mailgun, Testrail, Quints VPN

Initially, the project was deployed to servers through Capistrano, but gradually we moved away from this towards Docker and Docker-compose and later on to Kubernetes. We participated in making strategic hiring decisions and creating a separate DevOps direction.

To monitor the state of the application, we use:

• Sentry - to monitor exceptions in the application
• Grafana - for server resource monitoring

In addition, the project is heavily dependent on gitflow. For each client, a code fork is made from the main project. A special script was written that pulls all the changes from the main repository by fork-heirs. However, it is quite inconvenient and we are trying to get away from such an implementation.

DDoS attacks were recorded on the project many times. So, the rack-attack gem was added and configured against throttling and brute-force passwords. It is currently engaged in preventing DDoS ​​attacks.

We are gradually implementing new customer experience optimization solutions. Because the calculation of data in the application is smeared, both in code and in SQL queries, optimization affects both of these directions. When optimizing, we use standard tools, for example, RSpec-benchmark, RubyProf, StackProf, and MemoryProfiler.

Taking into account the import of data from the customer, we implemented interaction with various data sources. By default, the application worked with SFTP, but now it can work with Google cloud storage, as well as fetch data directly from the client API.

Quality Assurance

To coordinate the entire testing process on the project, we chose TestRail. This is a comprehensive solution for storing test cases and analyzing the results of runs, and a tool that allows you to make individual sets of cases for checks for different types of testing, and clearly shows the connection with automation.

The main focus in QA was on the backend and verification of mathematical formulas, which are used to calculate the parameters for each individual client. Some of the tests were universal for different types of clients and partners, but most of the cases were unique. This is due to the fact that the backend provides for different logic for calculating rates.

The main testing strategy was to create users with given parameters and maps of their further interactions with the website. We checked the correctness of the calculation of the commission for inviting new clients, adjusting the remuneration depending on the activity and duration of using the system, etc. It was necessary to provide for several dozen such scenarios, describe them and connect them with each other. The number of such role models directly depends on the scale of the project and its functionality.

Evrone provided two QA engineers full-time. There is also a customer-side automation engineer in the quality assurance team. Our experts support them in analyzing the logic of the system, determining how to ensure quality control, prioritizing test cases for automation, and implementing software quality control techniques.

Main challenges

One of the problems we faced was the incorrect calculation of statistics, either due to incorrect data from the client or an internal problem in the application. For example, at the end of last year, the activity on a number of subprojects had increased significantly. It had grown so much that the application could not keep up with calculations. We had to monitor the operation of the application for a full day, and in emergency situations, manually resolve the information received.

In addition, as we mentioned earlier, Quints has periodically experienced DDoS ​​attacks. However, our DevOps and Team Lead quickly sorted out these attempts to overturn the project, and the project has never become unavailable. We also encountered a problem with a hacker who registered in the system and started sending auto-generated traffic. But, we quickly figured it out and banned the activity.

Traffic distribution system

Initially, the Rails monolith could hardly handle the 600 RPS ad traffic load (clicks and banner views). Also, the Postgres database was growing, it had a hard time handling large amounts of data, and even partitioning did not help much.

One of the key corporate clients of Quints came up with new requirements for functionality and load. The new functionality should have included a flexible configuration of traffic redirection depending on different routing rules. For example, depending on the region of end-users, determined by the IP request, advertising campaign period, and other settings, it was necessary to redirect to a particular resource. So, we decided to implement a traffic distribution system (TDS), which serves as a middleman that buys and sells traffic between websites.

We wanted the system to withstand a workload of at least 2000 RPS, and decided to implement TDS as a separate system outside the monolith. Several architecture options were designed from scratch, with some functionality transferred from the monolith to the new system. We implemented the TDS on the basis of a microservice architecture, using the Roda (Ruby) microframework. For the storage of raw traffic data on clicks and views, we used the Clickhouse DBMS, which is capable of handling huge amounts of data per record and performing analytical queries for data aggregation with lightning speed. The Kafka was integrated to deliver data to Clickhouse. Kafka was also used to transfer aggregated data to the main Quints monolithic system.

As a result, we:

• Implemented TDS functionality
• Enabled any TDS component to be horizontally scalable
• Enabled it to withstand the load of 4000 RPS on one node (we can further horizontally increase the number of nodes, increasing the throughput of the system)
• Moved part of the functionality from the monolith to a new system that is easier to modify, maintain, expand
• Reduced the load on the main monolith application
• Reduced the load on the main Postgres storage

The result

Apart from developing and supporting the system itself, we also participated in building:

• A package of technical documentation for the software product
• Processes for predicting the delivery time of features and project launches
• The process of interviewing and hiring new employees
• Full-fledged onboarding processes, including a roadmap for studying text and video documentation, mentoring, and feedback
• Offboarding processes
• A process for creating monthly reports for end customers

A lot of time and effort was invested in building the development and interaction processes. Together with Quints, we are trying to establish the sharing of expertise and record keeping.

The project has seen excellent results, and the client was so impressed by our contributions, that they decided to increase Evrone’s presence on the project. Now, the Evrone team on the Quints project includes 12 backend developers, 3 QA engineers, an account manager, and a project manager who is directly involved in managing the project team as a whole, which includes more than 20 specialists.

If you’re looking to automate an affiliate business or you want to learn more about using an aggregator in gambling company management, feel free to reach out using the form below.