Better, faster... smaller?

Coming from a non-betting background into Colossus a few years ago, I was shocked at the extent to which the online betting industry lacked ‘real-time’ user engagement. Even today, if we look at well-established sportsbook websites, the user interaction usually takes place only twice – at the beginning (bet placement) and the end (settlement).

This equates to a wide gap in engagement everywhere in the middle and, from a commercial standpoint, a loss of opportunity. I was lucky to join a company that recognised this as an issue early on, especially since we specialise in pools betting, where the distance between individual legs means the pool often stays ‘in play’ for days and, thus, the ‘engagement gap’ is even longer than in fixed-odds betting.

We went on to introduce pioneering features, such as cash-out at every leg, in order to engage users in a more continuous manner. However, this commercial foresight gave our technology team a significant technical challenge as our system must be fast, always in sync and ready to serve real-time content.

Monolithic application vs microservices If you want the fastest path to get an MVP up and running, take the monolithic approach. But does it work in the medium term? Not at all. A monolithic application is complex to update, test and add new functionality to. What is more, adding real- time features to a monolithic application not designed for this purpose means changing so many internal flows that the task becomes (almost) impossible.

The first significant improvement to make is to split a monolithic application into microservices that communicate with each other. Every microservice is a small piece of code that is individually easy to maintain. In other words, it does one thing and it does it well. With microservices, we transfer the complexity from the application itself to the interactions between each component.

This way, adding new functionality requires only to add dedicated microservices and redesign the communication flow. For example, adding the ‘tweet my bet’ feature is simply a question of adding a microservice that prepares the message and tweets it, and is linked to the existing application components through a new flow.

How do the microservices communicate with each other? In the microservice paradigm, the communications are usually achieved through API calls, which is a valid approach in 90% of all cases. As it happens, there is also a 10% where that is not enough. These are situations where we need to guarantee that the messages reach the destination and maintain a consistent order. To accomplish this, we can add more logic to our code, or we can switch from an API approach to something explicitly designed for this purpose.

To cloud or not to cloud?

The cloud is one of the most exciting innovations of recent times. It allows scaling up horizontally without limit, managing infrastructure in a standard and automated way, and being present in multiple regions with reduced latency for users. But as with all high-potential innovations, it also comes with downsides.

Cost is one. Since the flexibility comes at a price, cloud environments are only cost effective when the system can scale up and down quickly. At Colossus, we ended up adopting a mixed infrastructure, usually known as a ‘hybrid cloud’, which was made possible thanks to the microservices approach I outlined above.

With the hybrid cloud, we do not have the costs of a cloud-only infrastructure but we enjoy all the benefits – the system is very scalable to handle peaks and is distributed worldwide, which improves the user experience of our real-time service even further.

Colossus Bets CIO, Alberto Zuin