Market data is sent by UDP multicast and orders are sent by TCP. Justify both choices on their merits, then explain the specific failure mode of using TCP for a market data feed with 3,000 subscribers.

Market data is sent by UDP multicast and orders are sent by TCP. Justify both choices on their merits, then explain the specific failure mode of using TCP for a market data feed with 3,000 subscribers.

Approach: Compare one-to-many fanout against one-to-one delivery, then consider what retransmission and flow control do to a shared stream when one receiver is slow.

Multicast UDP sends one copy that the network replicates, and it never lets one slow receiver delay another, which is exactly what a fanout feed needs; TCP is right for orders because each order needs guaranteed, ordered, acknowledged delivery to one destination. With TCP and 3,000 subscribers the exchange must serialise and send 3,000 copies of every message, so the last subscriber is thousands of send operations behind the first and the ordering of who gets data first is decided by the sender's loop rather than by the network. Worse, TCP retransmission gives head-of-line blocking: a single lost segment stalls delivery of every later message on that connection until the loss is repaired, one round trip minimum, and flow control means a subscriber whose receive window fills causes the exchange to buffer for it. On UDP a lost packet is a numbered gap the receiver can fill from the redundant feed or skip, and the receiver decides how much staleness it will tolerate. The cost is that loss detection and recovery move into the application, which is why every real feed carries sequence numbers and a snapshot channel.

Follow-up: Where does a reliable multicast layer with negative acknowledgements sit between these two, and what is the NAK implosion problem?

Key concepts: multicast, head-of-line blocking, retransmission, flow control.