The market-data feed handler

1. Receive packets from the A and B multicast feeds, often on different network cards, by kernel bypass.
2. Arbitrate: keep the first copy of each sequence number and discard the duplicate from the other feed.
3. Check sequence: compare each packet's sequence number with the next expected one; detect gaps.
4. Decode each message in the packet from the exchange's binary format.
5. Apply it to the book for its instrument: add, modify or delete an order, or a level update, or a trade.
6. Publish the result to strategies: the changed book, a top-of-book update, or the raw normalised event, through shared-memory rings.

Every packet on a feed carries a sequence number that increases by one (per channel; large exchanges split instruments across many channels, each with its own sequence and multicast group). The handler keeps next_expected per channel:

void on_packet(Channel& ch, const Packet& p) {
    if (p.seq < ch.next) return;                    // duplicate: the other feed already delivered it
    if (p.seq > ch.next) { ch.gap(ch.next, p.seq); }  // missing ch.next .. p.seq-1
    process(p);                                       // or buffer it while recovering (below)
    ch.next = p.seq + 1;
}

With two feeds, a packet lost on A is usually delivered by B, so the handler never sees a gap.

Arbitration is a race: whichever feed delivers a packet first wins. Feeds have different path latencies, and the faster one is not always the same one, so handlers arbitrate per packet rather than preferring one feed.

When both feeds miss a packet, the book is now wrong: an order may have been added, changed or deleted without the handler knowing. Options, in rough order of preference:

• Wait briefly for the missing packet: it may be reordered rather than lost. Buffer the packets after the gap meanwhile.
• Request retransmission of the missing range from the exchange's recovery service, usually over TCP, then apply the buffered packets after it.
• Rebuild from a snapshot. Exchanges publish periodic full-book snapshots, on a separate feed or on request, tagged with the sequence number they correspond to. The handler clears the affected books, applies the snapshot, then replays buffered incremental packets with higher sequence numbers.

Throughout recovery, the affected books must be marked stale and strategies told, so that nothing trades on a book known to be wrong. Getting this logic right, including the edge cases (gaps during recovery, snapshots that are older than the buffer), matters more than shaving nanoseconds, and interviewers often probe it.

Exchange protocols are binary: fixed-layout messages with a type byte and a length, little- or big-endian integers, prices as scaled integers (Module 10). Decoding is a switch on the type and memcpy of fixed-offset fields (Module 2), and it is one of the places where every branch and copy is visible in latency. Common tricks: generate the decoders from the exchange's specification; handle the most frequent message types first; keep instruments' books in an array indexed by a dense id mapped from the exchange's instrument id at start-up.

Feeds come in two styles. Market-by-order feeds (in the style of Nasdaq's ITCH) report every individual order: add order 123 at price p, execute 50 of order 123, delete order 123. The handler keeps every order and aggregates levels itself, which needs a hash map from order id to order (Module 3). Market-by-price feeds report changes to aggregated levels: the quantity at price p is now q. They are simpler to process and carry less information. Module 9 builds the book.

The handler is a single writer serving many readers. Common designs: a broadcast ring of normalised events (Module 6), plus a seqlock-protected top of book per instrument (Module 4) that strategies can read at any time. Strategies that need only some instruments filter early, so they do not pay for everything.