# Market Data Replay

> Market data replay feeds recorded live data back through a trading system to test, debug and benchmark it. Learn how to record, replay and stay deterministic.

Source: https://learn.tradelabsai.com/programming/market-data-replay/  
Track: Programming and Data · Level: Advanced · Updated: 2026-10-03  
Publisher: TradeLabs AI (https://tradelabsai.com). Education, not financial advice.  
Cite as: TradeLabs Learn, "Market Data Replay", https://learn.tradelabsai.com/programming/market-data-replay/

Market data replay means recording the exact data your system received live and later feeding it back through the same code, as if the market were happening again. It sits between a backtest and live trading: more realistic than a backtest because it uses the real message stream, with its gaps, bursts and timing, and safer than live trading because no real orders are sent. Replay is one of the best tools for finding bugs, reproducing incidents and checking that a new version of a bot behaves exactly like the old one.

## Replay versus backtesting

| | Backtest | Replay |
|---|---|---|
| Input | Cleaned historical bars or ticks | Raw recorded messages as received |
| Code | Often research code | The production system itself |
| Realism | Simplified | Real message order, bursts and gaps |
| Speed | Very fast | Real time or accelerated |
| Purpose | Test the strategy idea | Test the system and its behaviour |

See [Backtesting Methodology](https://learn.tradelabsai.com/research/backtesting-methodology/).

## What to record

- **Raw messages** from every feed, with the receive timestamp on each.
- **Periodic snapshots** of order books so replay can start mid day. See [Order Book Feeds: Snapshots and Incremental Updates](https://learn.tradelabsai.com/programming/order-book-feeds/).
- **Your own order events:** orders sent, acknowledgements, fills and rejects.
- **Configuration and code version** running at the time. See [Data Versioning, Lineage and Schemas](https://learn.tradelabsai.com/programming/data-versioning/).

Recording is cheap compared with the cost of an incident you cannot explain.

## Replay modes

| Mode | Use |
|---|---|
| Real time | Reproduce timing sensitive behaviour |
| Accelerated (for example 10 times) | Test a full day quickly |
| As fast as possible | Regression tests and benchmarks |
| Step through | Debug one event at a time |

## Determinism

A replay is only useful if the same input produces the same output every time. Sources of non determinism:

- **Wall clock time:** code that calls the system clock behaves differently on replay. Use a clock driven by the replayed timestamps instead.
- **Random numbers** without fixed seeds.
- **Multithreading** where event order depends on scheduling.
- **External calls** to live services during replay.

Designing the system so all time and input come through one event stream makes replay deterministic. See [Backtest Reproducibility](https://learn.tradelabsai.com/research/backtest-reproducibility/).

**Example: Reproducing an incident**
At 14:02 one afternoon, a bot sent three sell orders within a second instead of one. The trader replays that day's recorded feed from the 14:00 snapshot through the same code version in step mode. At 14:02:07, a burst of 400 book updates arrives in 50 milliseconds; the strategy's position update runs before the first fill message is processed, so it believes it still needs to sell and repeats the order twice. With the bug visible, the trader changes the logic to count working orders as pending position, reruns the replay and confirms only one order is sent. See [Building Trading Bots](https://learn.tradelabsai.com/programming/building-trading-bots/).

## Regression testing with replay

Before releasing a new version, replay several recorded days through both the old and new versions and compare every signal and order. Differences should be intended changes only. This catches accidental behaviour changes that unit tests miss. See [Developing, Testing and Monitoring Algorithms](https://learn.tradelabsai.com/algo-trading/algorithm-development/).

## Simulating fills during replay

Replay of market data does not tell you how your own orders would have filled. A simulated exchange can match your orders against the recorded book, using queue position assumptions. This is still an estimate: your orders would have changed the market slightly. See [Fill Models, Partial Fills and Order Queues](https://learn.tradelabsai.com/research/fill-models/) and [Fill Probability and Queue Position](https://learn.tradelabsai.com/orders/queue-position/).

## Frequently asked questions

### What is market data replay?

Feeding recorded market data back through a trading system to test, debug or benchmark it without sending real orders.

### How is replay different from backtesting?

Backtests usually run research code on cleaned data; replay runs the production system on the raw messages it actually received, including timing and gaps.

### Why must replay be deterministic?

So the same input always produces the same output, which makes bugs reproducible and comparisons between versions meaningful.

You have finished the Programming and Data track. Continue with the systems that run it in [Trading Infrastructure Explained](https://learn.tradelabsai.com/infrastructure/trading-infrastructure-explained/).

## Continue learning

- Previous lesson: [Exchange vs Receive Timestamps and Latency Measurement](https://learn.tradelabsai.com/programming/latency-measurement/)
- Related: [Exchange vs Receive Timestamps and Latency Measurement](https://learn.tradelabsai.com/programming/latency-measurement/): How to measure latency in a trading system: where to timestamp, tick to trade and order round trip, percentiles instead of averages and how to find bottlenecks.
- Related: [Backtest Reproducibility](https://learn.tradelabsai.com/research/backtest-reproducibility/): A reproducible backtest gives the same results every time from the same code and data. Learn version control, data snapshots, research logs and good habits.
- Related: [Building Trading Bots](https://learn.tradelabsai.com/programming/building-trading-bots/): How to build a trading bot that is safe to run: the main components, an event loop, state and position tracking, risk checks, logging and a staged path to live.
- Related: [Order Book Feeds: Snapshots and Incremental Updates](https://learn.tradelabsai.com/programming/order-book-feeds/): How exchanges publish order book data as snapshots and incremental updates, and how to build and maintain an accurate local order book in code without errors.
- Related: [Developing, Testing and Monitoring Algorithms](https://learn.tradelabsai.com/algo-trading/algorithm-development/): A step by step process for developing a trading algorithm, from idea and specification to coding, testing, review and staged deployment with real controls.
- Related: [From Backtest to Live: Paper, Shadow and Canary](https://learn.tradelabsai.com/algo-trading/backtest-to-live/): Why live results almost always trail backtests, how to measure the gap, and a staged plan for taking a strategy from backtest to paper trading to real money.