Design a Market Data Feed Handler

Start with what the thing on the wire looks like. An exchange does not send you a tidy REST response. It broadcasts a continuous stream of tiny binary messages over UDP multicast: an order was added at this price for this size, an order was cancelled, a trade printed, the auction imbalance changed. Each message is a few dozen bytes, each carries a sequence number, and they arrive back to back at a punishing rate. The feed handler is the piece that stands at the wire, reads that stream, and turns it into something the rest of the firm can use. Three jobs, in order: take the raw feed in, normalize it, and rebuild the book from it. That is the whole handler.

Normalize means one schema for the whole world. Every venue speaks its own dialect. Nasdaq sends ITCH, CME sends a Simple Binary Encoding feed, the consolidated options feed (OPRA) has its own layout, and their symbols and price scales all differ. A consumer downstream should not care which venue a quote came from. So the handler decodes each proprietary format and emits a canonical message: an instrument id, a side, a price in a fixed integer representation, a size, and a message type. After normalization, an ITCH add-order and a CME add-order look identical to everyone reading them.

Rebuild the book means the handler does not just forward messages, it maintains state. From the stream of adds, cancels, and modifies it keeps a live order book per instrument: the resting bids ranked high to low, the asks low to high, the size sitting at each price. Most consumers want that assembled picture, the current best bid and offer and the depth behind it, far more than they want the raw message firehose. The handler applies each incremental message to the book the instant it arrives and publishes the change.

Two forces bend every later decision, and they pull against each other. The first is latency, measured in microseconds and sometimes in nanoseconds per message.