Stop Obsessing Over Latency. Your Backtests Are Lying to You.

You’ve spent countless nights tweaking your strategy, convinced the final edge is just a millisecond of latency. But what if the real problem is much simpler—and much more dangerous?

Here’s the truth: Most backtests are secretly broken, and the culprit isn’t your data feed or your execution logic—it’s the way you replay market data. When your backtest runs today, it gives you one result. Run it again tomorrow, and you get a different one. You chalk it up to noise, but the real reason is that your system isn’t deterministic.

I’ve seen trading firms waste months—sometimes years—on strategies that looked brilliant in backtest but failed in production. The failure wasn’t because the market changed. It was because the backtest itself was a mirage. Every time they replayed the same historical data, tiny timing differences—a few microseconds here, a thread scheduling jitter there—cascaded into completely different outcomes.

Designing market data for deterministic replay means treating time and state as first-class constraints, not just data pipelines. Every replay must yield identical outcomes regardless of when or how it is run. That sounds obvious, but almost nobody gets it right.

Most architects obsess over data throughput and latency—how many gigabytes per second can we push, how fast can we calculate the order book? Those are important, but they’re not the bottleneck. The real bottleneck is consistency of internal state across replay invocations. This is a subtle, system-wide property that defies simple caching or logging.

Think about it: the market is inherently stochastic and chaotic. Tiny timing differences can cascade into divergent states. Your replay system has to impose a strict ordering on events and ensure that every single decision—which tick arrives first, which thread processes which message—is repeatable. That’s not a data problem; it’s a state management problem.

Neutrality is death here. If you don’t nail deterministic replay, your backtests are worse than useless—they’re dangerous. They give you false confidence, and false confidence costs real money.

So what do you do? First, commit to a single source of truth for time. Use monotonic clocks, not wall clocks. Second, make all state transitions explicit and serializable. Third, test your replay by running it twice and comparing every intermediate state, not just the final P&L.

I saw this firsthand when a friend’s fund spent six months optimizing a strategy that turned out to have a non-deterministic bug in the order-book reconstruction. The fix wasn’t more cores or faster networking. It was a complete rethink of how they logged and reordered market data events. They treated the replay problem as a systems design constraint from the ground up.

When you finally get deterministic replay working, the relief is palpable: finally, your backtests can be trusted. No more hidden bugs, no more wasted months debugging phantom strategies. You can reproduce production scenarios for debugging and for compliance. The emotional shift from suspicion to confidence is what every quant dreams of.

Here’s the contrarian take: the firms that dominate quantitative trading aren’t the ones with the fastest feeds or the deepest pockets. They’re the ones that treat deterministic replay as a non-negotiable foundation. Everything else—latency, throughput, models—is built on top of that bedrock. If your foundation is shaky, nothing else matters.

Your backtests are either deterministic or they’re fiction. Choose wisely.