{"id":5126,"date":"2020-10-01T08:45:12","date_gmt":"2020-10-01T07:45:12","guid":{"rendered":"https:\/\/sandbox.weareadaptive.com\/?p=5126\/"},"modified":"2020-10-10T13:56:02","modified_gmt":"2020-10-10T12:56:02","slug":"building-fault-tolerant-low-latency-exchanges","status":"publish","type":"post","link":"https:\/\/sandbox.weareadaptive.com\/fr\/2020\/10\/01\/building-fault-tolerant-low-latency-exchanges\/","title":{"rendered":"Building fault-tolerant, low-latency exchanges"},"content":{"rendered":"
\n

This article is the first in a series where we\u2019ll be sharing our experience of building fault-tolerant, highly-performant marketplaces.<\/p>\n

Before we discuss how we build bespoke marketplaces at Adaptive, let\u2019s consider an alternative: buying an off-the-shelf solution.<\/p>\n

\"\"<\/p>\n

Building a bespoke solution has the obvious benefit that we can tailor it to match requirements. For example, in a marketplace, we might introduce a novel matching algorithm or order type that domain experts think will improve liquidity. These are the kinds of customisation that are impossible, or at least prohibitively expensive, to achieve with an off-the-shelf solution whilst retaining the underlying intellectual property.<\/p>\n

On the other hand, building a bespoke solution is riskier. Building marketplaces typically requires a large team with in-depth knowledge both at the domain level and at the infrastructure level. An organisation may need to hire a team if it doesn\u2019t have enough capacity in-house. Hiring great people takes time and effort. Factors like this can lengthen the time to market beyond what it takes to develop a solution from scratch. What if a competing marketplace innovates first? How many people are needed to maintain the solution after its initial delivery? Can those people be retained?<\/p>\n

At Adaptive, we offer what we think is a compelling third option: a hybrid approach.<\/p>\n

Between 2012 and 2020, together with various clients, we\u2019ve built many trading systems, including exchanges and RFQ workflows, across different asset classes using similar architectures (read more about them in this blog post<\/a>). In the most recent of these deliveries, we had a budget of 100 microseconds to respond to a NewOrderSingle FIX message, i.e., a \u201cplace order\u201d instruction, with execution reports at the 99th percentile. Below is a birds-eye view of the key logical components in this system. We\u2019ll revisit it later in more detail.<\/p>\n

\"\"<\/p>\n

Over those five years, it became increasingly clear which parts of the architecture remained constant between projects. To offer better value to our clients and to accelerate their deliveries, we wanted to stop building these parts from scratch on each new project; therefore, back in 2017, Adaptive began to invest in a solution: Hydra Platform. Hydra Platform provides an opinionated architecture and building-blocks for the typical logical components that one would find in a trading system. It allows teams to focus on business logic and deliver value to the client straight away without having to worry about low-level details or cross-cutting concerns like how fault-tolerance or disaster recovery will work.<\/p>\n

\"\"<\/p>\n

Hydra Platform has and continues to be a compelling option for our clients.<\/p>\n