The challenges of running a betting exchange

Mika Boström
Smarkets HQ
Published in
3 min readJul 15, 2016

--

Operating a rapidly growing online betting exchange is never dull. While a commodities or futures exchange can shut down for routine maintenance at the end of each trading day, the requirements for an online system are more demanding. Our customers can, and should, expect Smarkets to be always available — 24 hours a day, 365 days a year.

As an exchange, we consider ourselves a financial technology company rather than a gambling enterprise.

When I interview engineers, one question comes up frequently - What are
our biggest engineering challenges?

The answer is never straightforward. Basically, all the problems circle around a holy trinity: high availability, low latency, and transactional integrity. High availability also goes hand in hand with scaling, which implies a distributed architecture. To adapt a quote by Leslie Lamport: “A distributed system is one where the failure of a machine you never knew existed can render your own system unusable.”[1]

High availability is easy to explain. Individual systems must be fault tolerant, and when they do fail, other systems that rely on them must fail gracefully. Load-balancing, replication, and over-provisioning are the standard tools for stateless systems — and as such we aim to design our systems stateless whenever possible.

However, there are systems where state is unavoidable. Sports trading is an industry where fractions of a second matter, and we operate with latencies at the edge — or even below — of human perception. UI research has shown that humans treat any response under 100ms as “instantaneous” and anything above that is perceived as having taken some time.[2]

So, for all trading activity we have a hard deadline of 100ms, including the transmission time in both directions. Browsers must complete the full network roundtrip within that time window. For majority of our customers, 100ms is not enough to even establish a new connection and perform the necessary TCP handshake, let alone transmit actual payload data. For that reason, we maintain a persistent connection between the browser and the Smarkets exchange. All price updates, as well as the trading actions, are sent over the persistent connection.

The benefits are obvious: we regularly achieve roundtrip times of 40ms, which leaves comfortable headroom to allow for unexpected processing delay. As long as we keep within the 100ms budget, our customers perceive no trading delay.

The third member of the trinity, transactional integrity, is the subtle and silent assassin. We must know at all times where and how each customer’s funds are allocated. After all, we operate on real money. Other people’s money.

When a trade is executed, we set aside the funds from the two parties’ orders into escrow. When the results of the event become available, the trade is settled, and we release the funds to the winning party’s account. The funds in question must be accounted for at all times. Otherwise we would be either destroying or creating money, an activity usually allowed only for banks.

For regulatory purposes sports trading is considered gambling, and therefore must follow different rules. One of the cornerstones is that customers must not be allowed to wager more money that they have available in their accounts. At Smarkets we view this rule inviolable.

Effectively, we have a serialised lock at the very bottom of our stack, which affects all architecture and system designs. In interviews I often quip that we have all the challenges of an investment bank, just without the neckties.

The answer to a simple question really is quite complex.

If you are interested in working on technical challenges like these, we’d love to hear from you.

--

--