Most market data infrastructure is judged by how it performs on an ordinary day. Steady message rates, predictable queue depth, clean recovery, comfortable headroom. Reported this way, average latency looks reassuring. It also hides the only failure mode that actually costs money: what happens in the small fraction of the trading day when volume, volatility, and message rates all spike at once.

Exegy’s 2026 State of Trading Infrastructure research puts a number on this. Across 61 firms surveyed, nearly three-quarters reported some form of disruption during periods of high volatility, ranging from latency spikes to dropped data to full outages. The report’s central finding is not that firms lack speed on average. It is that peak load and variability, not average traffic volume, have become the real constraint on infrastructure. A system that comfortably handles a normal session can still fall over in the minutes that matter most.

That is the uncomfortable part of this problem. The worst moments for infrastructure are the same moments that are most valuable for the business consuming that infrastructure: market open, a macro data release, an unscheduled headline. Average latency, measured across a full session, mathematically dilutes exactly the conditions worth designing for.

Why Average Latency Hides Infrastructure Weakness

An average blends together the ordinary and the extreme. A feed handler that runs at 20 microseconds for 99% of the day and spikes to 2 milliseconds for the other 1% can still post an average that looks excellent, because the extreme values are a small share of the total sample. The average is not wrong. It is just answering a different question from the one latency-sensitive infrastructure teams actually need answered. Very few trading decisions are made against a full-day average. Every decision that matters happens inside a specific window, and infrastructure only needs to fail during that window to cause damage.

This is also why a system can pass every normal monitoring check and still be fragile. If dashboards are built around mean or median latency, a serious tail problem can sit invisible for months, surfacing only on the handful of days a year when it is expensive.

Where the Stress Actually Shows Up

The trading day does not stress infrastructure evenly. A handful of recurring conditions account for most of the burst risk:

• Market open and close, when order flow, cancellations, and quote updates all concentrate into a short window.
• Scheduled macro announcements, where message rates across an entire asset class can jump within a single update cycle.
• Unscheduled volatility events, which behave like a macro announcement but arrive with no warning and no chance to pre-scale.
• Quote churn during fast markets, where market makers widen, requote, and cancel at a pace that multiplies message volume well beyond the trade count itself.

In each case, the strain is not just “more data.” It is a sudden change in the rate and shape of data, arriving with no ramp-up period for the infrastructure to adjust to.

What Happens Inside the Pipeline Under Load

When message rates spike faster than a system can process them, the effects show up in a fairly predictable sequence. Queues start to accumulate as inbound messages arrive faster than they can be consumed downstream. If that backlog is not drained quickly, buffers fill, and the system is forced to either drop data or fall behind in a way that compounds. Packet loss during a burst is particularly costly in market data specifically, because recovery mechanisms themselves consume bandwidth and processing capacity at the exact moment that capacity is scarcest.

Feed handler behaviour under load is often the clearest signal of whether a system was actually designed for this scenario or just happened to perform well under normal conditions. A feed handler that decodes messages efficiently at steady state can still fall behind under burst conditions if its buffering, threading, or memory allocation strategy was never tested against anything but average-day traffic.

p50 Is Not the Number That Matters

This is where percentile latency becomes more useful than a single average. p50, the median, describes a typical message. p95 and p99 describe what happens to the messages that are having a bad time, and p99.9 takes you deeper into the tail, exposing the small fraction of messages whose latency can be hidden almost entirely by averages and medians. Whether that tail is dangerous depends on the application’s own latency budget, but a system can have an excellent p50 and a genuinely troubling p99.9, and the two numbers can move in opposite directions depending on what changes in the infrastructure.

Jitter deserves the same attention as absolute latency, and it is a different problem. Jitter is the variability between one message and the next, not the raw speed of any single message. A feed that is consistently slow is often easier to plan around than one that is usually fast but occasionally unpredictable, because downstream systems can tune timeouts and buffers to a known worst case. Unpredictability is what breaks assumptions that engineering teams did not realise they were making.

The Bottleneck Often Isn’t the Feed

It is tempting to treat the feed itself as the thing to optimise, since it is the most visible part of the pipeline. In practice, downstream processing is frequently where burst conditions actually break a system, even when the feed itself keeps up. Normalization, book building, risk checks, and strategy logic all have their own capacity limits, and those limits do not necessarily scale with the feed’s. A feed handler that delivers cleanly at ten times the normal message rate provides no benefit if the application consuming that feed cannot process messages at the same rate without falling behind.

This is one of the more overlooked design questions in market data infrastructure: not “how fast is the feed,” but “where does the pipeline actually run out of headroom first, and at what message rate does that happen.” That answer is different for every firm and every stack, and it is rarely the component that gets the most attention.

Capacity Planning Around Peaks, Not Averages

The practical implication is that capacity planning built around average throughput is planning for the wrong day. A system provisioned to comfortably handle typical volume with some margin can still be several multiples short of what a genuine volatility event demands. CME Group’s own infrastructure changes illustrate how quickly these baselines move: CME has been raising the packets-per-second threshold on MDP 3.0 recovery feeds and continuing to add multicast groups as its product set expands, both signs that peak capacity requirements are rising independently of average-day volume. Infrastructure sized against last year’s typical session, or even last year’s peak, is not automatically sized for this year’s.

A more useful capacity planning exercise starts from the worst realistic burst a firm’s traded products have produced, adds a reasonable margin, and treats that number as the baseline requirement rather than the exception. Average throughput remains useful for cost planning. It is not the number that should drive architecture decisions.

How to Actually Stress-Test a Market Data Pipeline

• Replay real burst events, not synthetic load. Market-open, macro-release, and prior volatility-event data all produce a message pattern that is genuinely difficult to fabricate accurately.
• Measure the full percentile curve, not just the average or median, and track how p99 and p99.9 move as load increases rather than only at steady state.
• Test recovery under load, not just under quiet conditions, since packet loss and recovery mechanisms interacting with an active burst is a materially different scenario than recovery on an otherwise idle feed.
• Profile every stage of the pipeline independently, from feed handler through normalization to the consuming application, to find where headroom actually runs out first rather than assuming it is the feed.
• Test beyond the worst day on record. Historical peaks are a floor for stress testing, not a ceiling, given that both volumes and burstiness have been trending upward.

None of this replaces good average-case engineering. It supplements it with the measurement that actually predicts whether a system holds up when it counts.

Closing Thought

Average latency is a reasonable number to report and a poor number to design around. The moments that decide whether a market data pipeline was worth building are the ones that occupy the smallest share of the trading day and the largest share of the risk: the open, the release, the headline nobody scheduled. Infrastructure that is only proven on a quiet Tuesday has not really been proven at all.

Your market data system can look brilliant at 11:17 AM on a quiet Tuesday and still fail you precisely when the data becomes most valuable.

Designing for the worst one percent, rather than the average ninety-nine, is what separates infrastructure that performs from infrastructure that merely benchmarks well.