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.
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.
Sign up and get the full case study
- Get the 12 page case study in PDF format.
- Find out how Rikstoto transitioned to an event driven architecture.
- Learn to jump-start your own solutions.