Skip to main content

Case Study: Rikstoto

Learn how the company transitioned from layered web services to an event driven architecture.

Looking through the mud

Clarity is a big issue for Jan Ove Skogheim. As a system architect and developer for Webstep consultancy, his specialty is removing the mud caked onto his clients' IT architecture, to bring that clarity to their software systems.

After digging through layers of web services, hidden behind ambiguous titles and their tangled cobweb of connections, he understands that clearing away that mud can be a messy business.

The challenge

Skogheim’s team faced two primary challenges. First, changing the platform required modifying an existing production system, and could not upset ongoing business operations. We had to do this while keeping the internal and external clients of the platform fully functional, he remembers.

Secondly, Rikstoto had a “peaky” transaction profile. Every race day had around seven races with betting reaching a peak near pre-race closing time. We would go from a couple of bets a minute to 200-300 per second when we approached the deadlines, he says. Downtime close to the start of the race was just not acceptable.

Untangling layers of problems

With an architecture based on web services calling web services, Rikstoto was vulnerable to performance and scalability issues. It was very hard to protect against peaks because the synchronous request/response communication between boxes meant that the slowest individual thing would slow down your entire business operation, he explains. The architecture had multiple layers, with an overload of various services. We had something called adapter services, there were process and composed services, basic services, and protocol services, says Skogheim.