TCP vs UDP Multicast for Market Data

An exchange needs to send the same stream of price updates to thousands of subscribers simultaneously, with the lowest possible delay. The obvious choice — TCP, the reliable, ordered connection most internet software runs on — turns out to be the wrong tool for this specific job, and understanding why explains a design choice baked into nearly every market-data feed.

TCP guarantees every byte arrives, in order, retransmitting anything lost — but it does this with a unicast connection: one dedicated point-to-point stream per subscriber. Serving 5,000 subscribers means the exchange's server sends the same data 5,000 separate times, and TCP's retransmission logic means one subscriber's momentary packet loss triggers a resend and a pause for that connection, while the other 4,999 carry on unaffected — but the sender now has 5,000 independent streams to manage, each with its own buffering, acknowledgment tracking, and potential backpressure. UDP multicast instead sends each packet exactly once onto the network, and the network's routers replicate it to every subscriber who has asked to receive that multicast group — the exchange's send cost stays constant regardless of how many thousands of subscribers are listening, and there's no per-subscriber connection state to manage at all.

The tradeoff is that UDP provides no delivery guarantee and no ordering guarantee: a packet can simply vanish, or arrive out of order, and UDP itself does nothing about it. For market data this turns out to be an acceptable trade, because the alternative — TCP's automatic retransmission — actually works against the goal: if you lose the price update from three seconds ago and TCP retransmits it, you'd receive a stale price late instead of promptly, which for a real-time system is often worse than the gap being visible and requiring an explicit ask for a fresh snapshot. So feed handlers instead build their own lightweight reliability on top of UDP: sequence numbers on every packet let a client detect it missed one, and a separate, lower-frequency "gap fill" or "retransmission" service (or periodic full snapshots) lets the client catch up, on its own terms, without stalling the live stream waiting for old data.

Worked example: cost of a lost packet under each

Suppose an exchange sends 100,000 updates per second and one subscriber's link drops a single packet. Under TCP, that connection's stack detects the missing sequence number, requests a retransmission, and — critically — TCP delivers all subsequent bytes on that connection strictly in order, so every update behind the lost one queues up waiting, even though newer data is already sitting in the buffer. If the retransmission round trip takes 2 milliseconds, that subscriber can be stalled 2 milliseconds behind live, having missed roughly $100{,}000 \times 0.002 = 200$ updates' worth of real time before catching up. Under UDP multicast, that subscriber's feed handler detects a gap in the sequence numbers, keeps processing every subsequent packet immediately (they're not blocked by the missing one), and separately requests just the missing update via a retransmission channel or waits for the next periodic snapshot — staying live and current the whole time, at the cost of momentarily knowing it's missing exactly one specific piece of data rather than having it silently delayed.

What this means in practice

Nearly every major exchange's real-time market-data feed is UDP multicast for this reason, with feed handlers responsible for detecting gaps via sequence numbers and requesting targeted retransmission rather than relying on the transport layer to guarantee delivery. TCP remains the right choice for order entry, where guaranteed, ordered delivery of a specific instruction genuinely matters more than staying maximally current.