Market Data: Ticks, Depth, WebSockets

Every strategy, backtest and risk check is only as good as the data feeding it. Market data is the raw material of algorithmic trading, and handling it correctly is less glamorous than strategy design but far more consequential — a strategy fed wrong or stale data makes confident, wrong decisions. This lesson covers the three things you must get right: what data you consume (the levels), how you turn a stream into a live order book, and how you keep the live feed (over WebSockets) honest when — not if — it breaks.

The Levels of Market Data

Exchanges and brokers offer market data at different depths, and you pay — in bandwidth, processing, and sometimes money — for more. Choosing the right level for your strategy is the first decision.

• Level 1 (L1) — top of book. Just the best bid, best ask, and last traded price/quantity. Lightest and cheapest. Fine for many slower strategies that only care about the current price.
• Level 2 (L2) — depth by price. The aggregated quantity resting at each of the top N price levels on both sides — the shape of the book near the touch. This is what most algos use: it lets you see depth, estimate slippage, and gauge buying/selling pressure.
• Level 3 (L3) — the full order book. Every individual order and its add/modify/cancel events — the complete, granular stream. Heaviest by far, and really the domain of colocated professionals (market makers reading their queue position at each price level). Most retail strategies neither need nor can afford to process it.

Match the level to the strategy: a daily mean-reversion bot is happy with L1; a market maker needs L3. Taking more data than you need just adds processing load and latency (Lesson 5) for no benefit.

What a “Tick” Is, and How to Store It

A tick is simply one update — a single message from the feed saying something changed: a trade happened, or a quote moved. The word gets used loosely, but think of it as one event in the stream. The challenge is volume: on a busy instrument, and especially on a liquid Indian index-option chain near expiry, you can receive tens of thousands of ticks per second. Your data path has to ingest, parse and process that firehose without falling behind — because if you lag, you’re trading on stale prices. That performance requirement is exactly why the hot path is often C++ with lock-free queues (Lesson 5).

Two storage principles matter for honest backtesting later (Lesson 10):

• Store raw ticks append-only. Keep the original stream — every tick, as received — in an append-only log (and later in a durable store, Lesson 8). You can always rebuild depth, bars, or any derived view from raw ticks; you can’t recover raw ticks from a summary. This is your ground truth.
• Timestamp on arrival, not on processing. Record when each tick arrived, so that when you backtest, your strategy sees data with the same timing it really would have — no accidentally peeking at information before it was available. Sloppy timestamps are a quiet source of lookahead bias (Lesson 10).

Building an Order Book From the Stream

You rarely get the whole book in every message — that’d be wasteful. Instead, the standard pattern is snapshot plus deltas:

1. On connect, you request (or receive) a full snapshot of the current book.
2. Then you receive a continuous stream of incremental updates (deltas) — “add 200 at 101.50”, “cancel the order at 102.00”, “trade 50 at 101.75” — which you apply, in order, to your local copy of the book.

This is efficient, but it has a sharp edge: the deltas must be applied in the exact sequence the exchange sent them. Miss one, or apply two out of order, and your local book silently diverges from reality — you now think there’s liquidity that isn’t there, or a price that’s wrong, and your strategy trades on a lie. That’s why serious feeds attach sequence numbers to every message. Your job is to track them and verify there are no gaps: if sequence jumps from 1050 to 1052, you missed 1051, and your book is not trustworthy until you resync. A silently wrong book is worse than no book, because you’ll act on it with confidence.

This is also the first place the “treat data as hostile” instinct pays off: validate what you apply, and never assume the stream is perfect.

WebSocket Practices: The Feed Will Disconnect

Live market data for retail comes over WebSockets — a persistent connection your broker pushes updates down. The single most important fact about WebSockets in production is that they disconnect: networks hiccup, brokers restart, your process pauses. If you haven’t designed for reconnection from day one, your algo will eventually be trading on a dead or stale feed without realising it.

The practices that keep a live feed honest:

• Connect & authenticate. Open the socket, send your API key/token, and subscribe to exactly the instruments you need (subscribing to everything wastes bandwidth and processing).
• Snapshot, then deltas (above) — and track sequence numbers from the first message.
• Heartbeat / ping-pong. Most feeds send periodic pings you must answer, and send data regularly. If you’ve received nothing for N seconds — no data, no heartbeat — assume the connection is dead even if the socket looks open. A silently-dead connection is the dangerous case; a watchdog timer catches it.
• Detect gaps. Watch those sequence numbers. A gap means missed data; the moment you see one, mark your book untrusted and don’t let strategies act on it.
• Reconnect & resync. On any disconnect or detected gap, reconnect with exponential backoff (don’t hammer the broker), re-subscribe, and re-snapshot to rebuild the book from scratch. Never just resume applying deltas to a book you’re not sure is correct.

The golden rule that ties it together: a reconnect must re-snapshot and re-validate — a stale or gapped book trades on lies. Many real retail blow-ups aren’t strategy failures; they’re a feed that silently died or desynced while the algo kept confidently sending orders against a phantom book. Treat your data connection as a first-class, defended component, with health monitoring (Lesson 13) and a rule that no trading happens on an untrusted book.

Pitfalls to Avoid

1. Taking more data than you need. L3 when L1 would do just adds latency and load. Match the level to the strategy.
2. Applying deltas out of order or ignoring sequence numbers. Your book silently desyncs and you trade on a phantom market. Track sequences; resync on any gap.
3. Timestamping on processing, not arrival. Quietly introduces lookahead bias in backtests (Lesson 10). Record arrival time.
4. Not storing raw ticks. You lose your ground truth and can’t rebuild or re-backtest faithfully. Keep an append-only raw log.
5. Assuming the WebSocket stays up. It won’t. Build reconnect-with-backoff and re-snapshot from day one.
6. Resuming on a stale or gapped book. The worst case — confident trading on wrong data. No trading until the book is re-validated.
7. No feed health watchdog. A silently-dead connection looks fine until you’ve sent orders into the void. Alert on data silence.

Quick Recap

• Market data has levels: L1 (top of book), L2 (depth — most algos’ choice), L3 (full book — colo territory). Match the level to the strategy.
• A tick is one update; busy option chains fire tens of thousands per second, so the data path must keep up (Lesson 5).
• Build the book from a snapshot plus sequenced deltas; a missed or reordered delta silently corrupts it — track sequence numbers.
• Store raw ticks append-only, timestamped on arrival, for honest backtests.
• WebSockets will disconnect: authenticate, heartbeat, detect gaps, and reconnect + re-snapshot. Never trade on a stale or gapped book.

Next lesson: the engine at the centre of every exchange — the matching engine. We’ll see exactly how price-time priority turns an incoming order into fills, and write a small one.