Cases — systems we built and keep running · Codelabs
RU|EN|KK

12 CASE

What we have already built

Twelve systems, each of them in operation rather than in a portfolio of prototypes. The figures come from working products and are not rounded up: if it says 1.24 million, that is exactly what it is.

CASE 01Turnkey iGaming platform

A gaming platform used by 2 million people

The operator needed not a single game but the entire business: a site for players, a cash desk in physical venues, an admin panel for staff, in-house games, third-party games, payment acceptance, an affiliate programme. We built it as one system — and 15 different brands are launched from that same system, each with its own look, without copying the code for every one of them.

PlatformPaymentsHigh load
Read the case →
  • ·2.18M players
  • ·~1.5M money operations per day
  • ·15 brands from one codebase
  • ·the database is spread across 13 servers
CASE 02Moving history into a columnar store

The hot database shrank 45-fold, and payments never stopped

The money journal had grown to hundreds of millions of rows, and everything touching it was slowing down. We left one day in the main database instead of forty-five and sent the whole history into a separate store, streaming, with a lag of seconds. Every report was switched to the new read one at a time, in small releases, and at each step the old answer was reconciled against the new one: the difference had to be zero. It was.

DataMariaDBClickHouse
Read the case →
  • ·hot database: one day instead of 45
  • ·the full history is kept
  • ·reconciliation at every step: difference 0.00
  • ·payments were never stopped
CASE 03Real-time betting pipeline

Odds that keep up with the match

A bookmaker receives a stream of odds changes across 12 sports. They have to be sorted by match instantly and pushed to every open browser so that nobody sees a stale price and manages to bet on it. We wrote our own core in C++ and our own delivery protocol for this: if a player loses the connection, they get a correctly restored picture rather than garbage.

Real-timeC++Betting
Read the case →
  • ·12 sports in one stream
  • ·in production since 2020
  • ·the same stream is sold to partners as a separate product
CASE 04Performance engineering

Bet settlement made 15 times faster

The platform held an ordinary day, but on a popular match the bets arrived in an avalanche and settlement queued up. We wrote a load generator, reproduced that peak hour on a test bench and saw the culprit: settlement ran in a single stream. Once we split it across independent lanes, the rate grew almost fifteenfold, and the fix went to production.

LoadOptimisationBetting
Read the case →
  • ·from 290 to 4360 bets per minute
  • ·load: 274 virtual players
  • ·verified across 123 543 bets
  • ·zero double payouts, zero lost credits
CASE 05Crypto payment gateway

Crypto payments across 10 blockchain networks

The task sounds simple: the client pays in crypto and the business receives money in local currency. Everything else hides behind that simplicity — give every client their own address, spot the incoming payment in the blockchain, wait for confirmations, check where the money came from, calculate the rate and not lose on it. We assembled all of that into one system.

CryptoPaymentsAML screening
Read the case →
  • ·more than 85M operations
  • ·10 networks: Ethereum, TRON, Solana, TON, Bitcoin and others
  • ·the rate is calculated automatically from orders on exchanges
CASE 06Live video and remote equipment control

Playing a real slot machine from a browser

A person opens the site and sees live video of a real slot machine standing in a hall. They press a button on the screen — and it is pressed on the machine itself: the signal goes from the browser to the server, from the server to the board inside the cabinet, and the board closes the contact. The reels spin, the camera shows the result, the money is counted exactly as it is for a visitor standing in the hall. We did everything here: from the board firmware to the client that shows the video.

VideoElectronicsWebRTC
Read the case →
  • ·about 1000 machines online
  • ·1998 simultaneous video streams
  • ·our own board and our own firmware inside the machine
CASE 07IoT tracking and local positioning

A sensor on a footballer and a heat map of the pitch

A coach needs to see how far a player ran, where they were on the pitch, how often they accelerated and what is happening to their heart rate. We developed a wearable tag — drew the board ourselves, wrote the firmware ourselves — placed receivers around the stadium and wrote a server that computes every player position from the radio signal. The coach gets a live map of the pitch during the match and heat maps after it.

IoTSportElectronics
Read the case →
  • ·our own board: radio module, motion sensors, ECG, GPS
  • ·position is computed from the radio signal of several receivers
  • ·the charging capsules for the tags are our development too
CASE 08Lottery platform

A national lottery moved into digital form

Bets are taken both online and at ground cash desks with paper receipts, while the results come from official draws. We wrote the result parsing, a payout calculation that cannot run twice, five bet types with odds up to 25,000 and a jackpot that funds itself. Partners get all of it as a separate module with its own integration kit.

LotteryPaymentsCash desks
Read the case →
  • ·online and an offline network of cash desks
  • ·five bet types, odds up to x25000
  • ·double payouts ruled out at settlement level
  • ·shipped to partners as an embeddable module
CASE 09Money transfer network

Cash sent from one country and collected in another

A person hands cash over at a desk in one country, and the recipient collects it in another with a transfer number and a four-digit PIN. The fee is split automatically between the accepting outlet, the operator and the paying outlet. Every request and every response is cryptographically signed, all operations go into two independent journals, and after ten wrong PINs the transfer is blocked.

PaymentsCash desksFintech
Read the case →
  • ·cash payout by PIN at an agent outlet
  • ·three parts of the fee distributed automatically
  • ·conversion between three currencies
  • ·double journalling of every operation
CASE 10SMS infrastructure

SMS delivery where no reliable aggregator exists

In a market where the usual messaging services do not work, we went through four generations: hardware GSM gateways, direct operator integrations, automation of a closed operator portal and, finally, our own Android application turning ordinary phones into gateways. All generations ran through one queue and one set of templates.

SMSAndroidIntegrations
Read the case →
  • ·about 7.5 thousand SMS a week
  • ·routing by the operator of the number
  • ·templates for 12 brands
  • ·a phone as an inbound SMS gateway for password-free login
CASE 11Protocol emulators and acceptance

Cash desk software replaced without a single discrepancy

The cash desk software was being replaced, and it had to be proven that the new system counts exactly as the old one did. We wrote an emulator for every gaming client — twelve of them — ran thousands of bets through them and reconciled the reports of both systems line by line. Any discrepancy failed the build, so "it seems to add up" became a verifiable fact.

QACash desksAutomated tests
Read the case →
  • ·12 emulators of network protocols
  • ·thousands of bets per run
  • ·every win checked against the odds tables
  • ·a discrepancy means a red build in CI
CASE 12Reporting over large tables

Report exports that stopped breaking off

Cash desk reporting was exported synchronously: forty-odd seconds of waiting and a timeout on longer periods. We moved the export into a background job with a progress indicator, and the reading onto a cursor with constant memory use. Along the way we learned to show the number of pages without recounting the whole table and to jump to the last page in seconds.

ReportsPerformanceData
Read the case →
  • ·a table of 90 million rows
  • ·the export no longer breaks off on timeout
  • ·page count estimated to within 0.1%
  • ·screen and file kept in step by an automated test

Describe your task — we will tell you what part of it we have already built