Direct Answer

An order book goes out of sync when a locally-maintained copy misses or misapplies an update relative to the exchange’s true state, most commonly because of a sequence gap, an out-of-order message, or a snapshot that was taken at the wrong point relative to the incremental updates layered on top of it, and once that happens, the book stays wrong until it’s explicitly resynchronized. Many depth-of-book implementations reconstruct state from a baseline snapshot or recovery image and then apply a continuous stream of incremental order events, each tagged with a sequence number so the client can confirm every update was applied in order. Nasdaq TotalView-ITCH, for example, is itself an incremental event feed; a companion snapshot/recovery service such as GLIMPSE establishes the starting state and identifies the corresponding ITCH sequence number, after which the client continues processing the incremental stream from that point. If an update is dropped, arrives out of order, or the snapshot and the first incremental update don’t line up on the same sequence boundary, the local book silently diverges from the real one, and every price level built on top of that error is wrong until the book is resynchronized. Detecting this requires validating sequence continuity on every incoming update, not just trusting that messages arrived in the order they were sent.

Why This Matters

A desynced order book doesn’t look broken. Prices still update, spreads still look reasonable, and nothing crashes, which is exactly why it’s dangerous: a strategy or risk system making decisions off a silently wrong book can act on a spread, depth, or price level that doesn’t actually exist in the market. The failure is invisible until a fill comes back different from what the book showed, or a risk check passes on a position size that was calculated against corrupted depth data.

This matters more under load. A single dropped or reordered message during a quiet period might briefly show a stale price level that self-corrects on the next update; the same event during a high-volume burst can leave a whole section of the book wrong for longer, precisely because the volume of subsequent updates makes it harder to notice a level that stopped updating for the wrong reason versus simply having no new activity.

Structural / Comparative Analysis

A book-building implementation without sequence validation applies every incoming delta to its local state in the order it arrives, trusting the network and the exchange to deliver messages in order with nothing missing, so a single dropped or reordered delta corrupts the book with no signal that anything went wrong. A properly built implementation checks each delta’s sequence number against the last one applied, and on any gap or mismatch, triggers the recovery procedure defined by that feed — for example retransmission, gap fill, a spin/recovery service, or a fresh snapshot — rather than trying to patch the existing, now-unreliable state.

Data Flow: client establishes an initial baseline state via a snapshot or recovery service (tagged with a starting sequence number) → client applies subsequent incremental messages only if each one’s sequence number is exactly the expected next value → any gap or mismatch triggers the feed’s defined recovery procedure (retransmission, gap fill, a spin/recovery service, or a fresh snapshot) → book is only trusted once continuity has been restored from that recovery point.

Real-World Pattern

(Illustrative scenario, composited from common infrastructure patterns, not a specific named client)

An engineering team supporting a market-making strategy noticed occasional fills that didn’t match what their internal order book had shown moments earlier, with no obvious pattern to when it happened. Logging every delta’s sequence number revealed the actual cause: during brief bursts of high message volume, a small number of deltas were arriving with sequence numbers that skipped ahead, meaning earlier deltas had been dropped somewhere upstream, and the book-building code was applying whatever arrived without checking for the gap. The book had been silently missing individual price-level updates for months, self-correcting only when unrelated messages happened to touch the same levels later. Adding explicit sequence validation, with an automatic recovery procedure on any detected gap, eliminated the mismatched fills.

Common Mistakes

•       Applying every incoming delta to the local book without checking that its sequence number is exactly one more than the last one applied.
•       Trying to patch or partially repair a book after a detected gap instead of triggering the feed’s defined recovery procedure (retransmission, gap fill, a spin/recovery service, or a fresh snapshot).
•       Assuming a book that “looks reasonable” (no crossed prices, no negative sizes) is therefore in sync, when a desync can look structurally valid while still being factually wrong.
•       Not logging sequence gaps at all, so the team has no way to measure how often desync events are actually happening.

Frequently Asked Questions

Q: How do I know if my order book is out of sync?

A: Track the sequence number on every incoming delta and compare it against the last one you applied; if you see a gap or an out-of-order number and you’re not checking for it, your book can already be wrong without any other symptom.

Q: Can a desynced order book be repaired without a fresh snapshot?

A: Not reliably; once a delta has been missed, you don’t know exactly what changed, so the safest approach is to trigger the feed’s defined recovery procedure — retransmission, gap fill, a spin/recovery service, or a fresh snapshot, depending on the protocol — rather than guessing at a patch.

Q: Does a snapshot-plus-delta model guarantee my book stays in sync?

A: Only if the client actually validates sequence continuity on every delta; the model provides the information needed to detect a desync, but it doesn’t prevent one, and a client that doesn’t check will still drift silently.

Audience Validation & Actionable Directive

For: Engineers building or maintaining a local order book from a snapshot-plus-delta market data feed.

Not For: Teams consuming only top-of-book or last-trade data with no locally-maintained depth-of-book state to keep in sync.

What to Do Next: Add explicit sequence-number validation to your book-building code if it isn’t already there, and confirm that any detected gap automatically triggers the feed’s defined recovery procedure rather than just a log entry.

About NxCore

NxCore delivers exchange-level market data as a raw, un-aggregated, tick-by-tick stream, giving infrastructure teams the sequence-numbering foundation to build and validate their own order book reconstruction rather than relying on a black-box, pre-built book they can’t independently verify.

Related Reading

Within this batch: “What Is Market Data Packet Loss and How Do You Detect It?” for the underlying network-level cause of most desync events, and “What Is Market Data Replay and How Does It Work?” for how teams reconstruct exactly when and where a book diverged.

Also on nxcoredata.com: Market Microstructure Explained Simply: What Every Trader Should Know (blog)

From earlier AEO batches: UDP vs TCP for Market Data Delivery (September) | Identifying Common Financial Data Quality Issues

Sources

Nasdaq — TotalView-ITCH specification (order book message types for add, modify, and delete); FINRA — CAT NMS Plan, CAT Alert 2020-02 (clock synchronization deviation reporting standards).