[CASE STUDY]
active tickets per month
vCPU per cluster
of data per cluster
In 2023, the European sports betting industry market size was estimated at $33.75 billion. In order to operate, businesses must acquire licenses to do business, and then they must comply with strict regulations to retain the license. Oftentimes this requires the capability to control where data resides which is difficult to accomplish with certain legacy solutions.
Additionally, spikes in traffic as a result of major sporting events generate heavy reads and writes and may complicate processing payouts – making the choice of database extremely critical. For example, Superbet’s Tickets Service stores information for up to 100M+ active tickets per month. The information relevant for each transaction is stored in a ticket – a binding contract with the customer.
Not only must the data be consistent for the customers, but also, since bets can be made months in advance, they must be stored for variable amounts of time. If data was lost or inaccurate, not only was Superbet at risk of losing customers, they were at risk of losing a license.
When Sergej Jakovljev, Site Reliability Engineer at Superbet, began working with Superbet, his team was operating on an on-prem system built on top of MongoDB. At the time, their system was TTL heavy with millions of rows expiring on a regular basis, leading to some compaction issues, clogging up their data store, and dragging down performance. The existing schema also resulted in inefficient sharding, creating further overhead. As Sergej’s team looked to refactor their application, they also explored alternative solutions that would better support future scaling ambitions.
If the team were to switch to a whole new system, they wanted a database that could:
Horizontally scale without sharding, as they expected 10x growth in the following 3 years
Geo-partition to locations that required data and processing in the license country
Guarantee high availability via a durable key-value store
Ensure regulatory compliance via a flexible distributed solution
This was when they found CockroachDB.
CockroachDB checked all the boxes. As I see it, CockroachDB is a really scalable key-value store that has all the features that you would want, like out-of-the-box backups, support for secondary indexes, automatic data sharding, and rebalancing. There are no hacky workarounds. You don’t need to reinvent the wheel for each use-case. It just works.
-Sergej Jakovljev,Site Reliability Engineer, Superbet
The DevOps team started with CockroachDB on-prem as the single source of truth for their data. There were a number of key benefits that CockroachDB offered as compared to other databases on the market. First, CockroachDB automatically clears up time to live (TTL) data, solving their data compaction issue. This helps to ensure regulatory compliance, efficient storage, and reduced overhead.
At the time, the team knew that to handle their anticipated business growth, they would have to move applications from running on-prem to running in the cloud. They ultimately chose to migrate to AWS knowing that a cloud migration is a complex process, and the business had to keep running. Since CockroachDB can run on-prem and in a hybrid cloud environment, CockroachDB would be able to support Superbet’s entire cloud migration from start to finish. For more granular management control, the team chose to self-host a CockroachDB deployment on AWS.
Two of Superbet’s key markets are Romania and Poland, which used to require data to be processed in the licensing country, but AWS did not have an availability zone in either location. Luckily, CockroachDB can run anywhere and allows you to control where data lives. Therefore Superbet could leverage a mix of running on-prem in those countries and also on AWS in other locations.
As you can see from the diagram, CockroachDB’s hybrid cloud capability provided the necessary infrastructure for the eventual migration off of their on-prem infrastructure.
Beyond the seamless cloud migration, CockroachDB also offers online schema changes. For example, as more data came in and the business continued to evolve, engineers could add columns or change the database without taking down the whole database and reconfiguring it. This ensured minimal impact to customers. Additionally, since CockroachDB is PostgreSQL compatible many developers were already familiar, ensuring a smooth transition for the whole team during the migration process.
Because CockroachDB is a distributed SQL database, it’s really resilient. This allowed us to start really small and grow on demand.
-Ivan Hrastinski,Engineering Manager, Superbet
Spin up your first cluster in minutes. Start with $400 in free credits.