How do you design a system that handles 7,000,000+ product price changes per day, 160TB of data flowing through your network, at peak 460 transactions per second, 3 billion transactions per year. We trade globally, taking and settling the millions of bets placed during the Grand National, World Cup, Euros, Cheltenham, Melbourne Cup, Superbowl, from the smallest local event to the biggest globally.

How do you make such a system resilient to failure, robust enough to route around slow or out of service components, flexible enough to be operated and upgraded without downtime and elastic to cope with the peaks and troughs of the sporting calendar.

We will look at the problems presented by an existing traditional database centric architecture, and examine some architectural patterns that we are exploring for our new sports betting systems - a micro service active/active/active stream based architecture, deployed with docker where every container is treated as ephemeral which may be taken out of service at any time, where multiple systems compete to do work, and are spun up or down according to load, a system where data flows to where it is required.