Design Patterns for Market Data – Part 3: Conquering the Compromises
*Originally published on LinkedIn
Series Summary
In this third and final installment in our Design Patterns for Market Data series, we cast a vision for a new design pattern that achieves the design aspiration we articulated in Part 1 of our series:
“Always present the necessary market data to my applications as soon as it’s published, regardless of trading volumes or the number of consuming systems.”
Our vision overcomes the longstanding tradeoffs inherent in the two leading design patterns that we covered – embedded software feed handlers and centralized ticker plants. The hyper-competitive nature of capital markets relentlessly raises the table stakes for speed, capacity, and capability of trading infrastructure. The impact of design compromises on market data solutions are increasingly meaningful for market participants in terms of lost opportunity, eroding returns, deteriorating execution quality, increased operational risk, and higher operational costs.
Removing these compromises would be a welcome innovation for those facing the challenge of identifying, building, and maintaining profitable trading applications.
We conclude this series with our vision of what’s possible with state-of-the-art computing and communications technology. Spoiler alert: the compromises can be conquered and Exegy is committed to making our vision reality.
Counting the Compromises
First, we revisit the key design considerations for market data solutions and summarize the strengths and weaknesses of the leading two design patterns.
Speed
Many trading applications are dependent on the speed of market data access – market making, latency arbitrage, and various forms of opportunistic taking of mispriced orders. The performance of other types of trading applications is highly sensitive to market data speed, including smart order routers and execution algorithms. In general, many trading applications benefit from consistently receiving market data as quickly as possible and removing data latency and jitter as another variable in optimizing trading results.
Without the other design considerations below, most trading system designers would simply choose embedded software feed handlers that deliver actionable market data in approximately 2.5 microseconds. Embedded software feed handlers can deliver market data faster since they remove the network hop(s) and associated transmit/receive delay(s) of centralized ticker plants.
These additional overheads can easily triple the latency of market data delivery from a centralized ticker plant to a trading application. Latency jitter can also be amplified by congestion in the network between the centralized ticker plant and the servers hosting the trading applications.
Availability
Our aspirational design statement begins with the word “always”. Availability is paramount in real-time trading systems that transact billions to trillions* of dollars in notional value daily. Resiliency is a primary means of delivering availability where backup systems continuously operate “hot” and takeover when primary systems fail. While both design patterns can leverage resiliency, failover events are inherently more disruptive with the embedded design pattern.
A fault in a software feed handler is likely to interrupt the operation of the trading application running on the same host machine. This requires a failover event at the trading application level which can induce longer disruptions in trading activity, cancelation of pending orders at exchanges, etc.
Conversely, trading applications can be isolated from a fault in a feed handler within a centralized ticker plant. Failover to a backup source within a ticker plant or application failover to a backup ticker plant can be done with limited data latency and no further impact to the trading system.
*The most recent Bank for International Settlements survey reported an average of $7.5 trillion turnover per day in foreign exchange spot and OTC derivatives markets.
Scalability
The relentless increase in data rates of real-time feeds requires market data solutions to efficiently scale input, processing, and distribution capacity. Budgeting for 20% to 40% increases annually in data rates is typical. For software feed handlers, this generally requires horizontal scaling by adding 20% to 40% more compute capacity per year.
For the embedded design pattern, the compute capacity increase requirement is multiplied by the number of trading applications. While this might be acceptable for trading systems with a small number of applications trading on a single market, it becomes untenable for large scale trading systems in high volume markets.
The solution is to use a centralized ticker plant design pattern that only incurs the horizontal scaling cost once. While this results in dramatic cost savings, it incurs the previously discussed latency penalties. This unfortunate trade-off is amplified as trading activities are expanded to multiple markets, and each trading application requires aggregated pricing views. Smart order routers and execution algorithms for equities and options in the United States are a primary example.
Efficiency and Cost
This US equities example was used to quantify the cost of performance and efficiency in this article series. In Part 1, we explained that achieving consistent speeds of approximately 2.5 microseconds with embedded software feed handlers requires over-provisioning CPU cores which can consume up to 50% of a host machine’s total compute capacity.
Operating a trading system with 32 to 64 applications hosted on servers in a co-located datacenter incurs 480,000 USD to 960,000 USD annually for processing real-time market data. It is critical to note that market data licensing, software licensing, network connectivity and bandwidth, in addition to operational personnel are all additive to these costs.
By contrast in Part 2, we showed that a centralized ticker plant can reduce the annual operating costs for processing real-time market data by 6x to 11x. This offers an order of magnitude improvement in efficiency; however, the cost of increased market data latency and jitter can outweigh the benefits. Many firms struggle to precisely quantify the improvement in trading returns caused by a specific market data latency improvement. Navigating these design pattern tradeoffs often devolves into a qualitative judgement call or practical budget constraint.
Final Score
Embedded software feed handlers win on speed by a factor of three or more. Centralized ticker plants win on scalability, efficiency, and cost by a factor of six or more. They also can offer superior availability through better resiliency and isolation of trading applications from embedded feed handler faults. For years this performance versus capability tradeoff has forced market participants to accept unacceptable compromises in their mission-critical trading systems. Surely, there is a better way.
What If…
- What if a centralized ticker plant could achieve better latency and jitter than an embedded software feed handler?
- What if that level of performance could be achieved inclusive of the additive latency of data distribution over a network and processing by an API?
- What if that centralized ticker plant could fit in the footprint of a single server in the data center?
- While we are dreaming, what if the client API only required one CPU core to present the necessary market data to your trading application regardless of the volume of data?
Is it possible? 18 years ago, Exegy launched the first ticker plant appliance powered by field-programmable gate array (FPGA) technology that drove centralized ticker plant latencies from milliseconds down to microseconds. One year ago, Exegy set a new speed record for tick-to-trade latency of 13.9 nanoseconds using the latest AMD FPGA platform. With our relentless commitment to solving the most challenging performance problems in capital markets, our answer is a resounding yes, it’s possible.
We can’t wait to show you how!
Want a first look? 👉 Contact us to learn what’s coming next.
