Deterministic Replay for Trading Systems

The most expensive production bugs in trading systems are often not the ones that crash. They are the ones that cannot be reproduced. A signal changed, an order decision differed, a timeout fired in a different order, and the system no longer has enough recorded context to explain why.

Deterministic replay is the discipline that makes that unacceptable.

The rule

A run should be explainable from its recorded inputs. That means external inputs are sequenced, time is explicit, state transitions are journaled, and hidden wall-clock dependencies are pushed behind narrow boundaries.

In practice, this requires more than logging. The system needs:

• A journal that records the ordered inputs.
• A reducer or state-transition layer that can run from the journal.
• An injected clock rather than direct wall-clock reads.
• Stable timer semantics for replay.
• Tests that compare live and replay behavior.

Time is the hard dependency

Most replay designs fail at time. The code path reads the system clock, sleeps against real time, or lets timer wakeups interleave with input handling in a way that was never recorded. Once that happens, replay becomes a simulation, not a reconstruction.

FerroReplay isolates that dependency with a clock boundary. Production code can use a monotonic system clock; replay can use a virtual clock; both paths keep the same interface. That gives Anvil a runtime substrate where replay is not a separate test harness, but a property of the system design.

Why it matters commercially

Replay is not only an engineering convenience. It supports post-trade review, risk review, customer support, regression testing, and investor-grade operational discipline. If a product ranks candidates, rejects a structure, or emits an execution intent, the path to that result should not disappear after the session ends.

Deterministic replay is how a trading system keeps its own memory honest.