Sky Bet Club is the weekly reward scheme on the Sky Bet club website / app. If customers reach the monetary target of required bets placed, then they receive a reward. This initially was a set reward of a free bet but grew, so the customer could choose their reward from several options such as Free spins on Sky Bet Games.

This was a very manual process where qualifying customers where manually taken from a CRM and exported into a MySQL database to show that they had qualified on the Front end.

One of my first projects at Sky Bet was part of an initiative to automate this manual process.

From my squad's perspective this involved receiving messages onto a Kafka topic for both the rewards configuration (amount of reward i.e. £5 free bet) and customer's progress into receiving that reward i.e., they had placed £5 worth of bets towards a £25 required amount.

The message data was then consumed by microservice applications written in Kotlin (a separate reward consumer app and a separate progress consumer app).

The data was then written to tables in the previously mentioned MySQL database. This data was consumed by a Node.js / TypeScript REST API as part of the backend for frontend strategy.

The React Frontend interacted with this API to show a tracker to the customer and their chosen reward. The Frontend also gave the option for a customer to opt-in / opt-out of the scheme and to change their reward.

This was a POST request to the API, which in turn called an API owned by the same squad which supplied the progress / reward data, following microservice principles.

Going back to the reward configuration, not all data required for the Front End display was sent onto the Kafka topic (as it was not available.), so part of this project was to create CMS functionality to create the data directly into the MySQL database using PHP and an existing CMS.

This system at peak^ had to be able to handle hundreds of requests per second to the API as the tracker was shown on the bet-slip (so whenever a customer placed a bet). The equivalent was required with the consuming of progress messages (a message being placed on the queue whenever a bet was placed whether a customer has opted in or not~).

^ Peak traffic is during international Football tournaments and Grand National and Cheltenham Horse racing festivals.

~ This meant when a customer opted-in, the progress data was already available to the Front End.

NOTE: This system is no longer used by the current Sky Bet website / app as a transformation project has just finished to migrate all Flutter Entertainment UK & Ireland brands onto a single system.