Trading Feeds Need Conflation, Not Every Tick

If you are streaming market data to a trading UI, do not try to deliver every tick. A liquid instrument can print thousands of price updates a second. A human staring at a screen cannot perceive more than a few refreshes a second, and a chart cannot render faster than the frame rate. Pushing every tick over the socket burns bandwidth, melts slow clients, and shows the user nothing they can act on. The right design conflates: you keep the latest value and send it on a cadence. Conflation, not raw throughput, is what makes a trading dashboard both fast and cheap.

Why more ticks is not more useful

Traders care about the current price and recent movement, not a lossless replay of every microsecond. For a display feed, the value of an update decays the instant a newer one exists. If three price changes happen between two frames, the first two are already stale. Delivering them costs you and helps no one.

This is different from an execution feed, where every fill and every order-book change matters and must be exact. Keep those two things apart. The order book and fills are a system of record with strong delivery guarantees; the price ticker is a display feed that can drop intermediate values safely. Conflating a system of record is a bug. Conflating a display feed is the whole point.

What conflation actually does

Conflation means: for each symbol a client subscribes to, hold only the most recent value, and flush on a timer or on a per-client budget. If price updates arrive at 2,000 per second and you flush at 10 Hz, each client gets 10 updates a second per symbol, always the freshest. You threw away 1,990 stale values that would have rendered as nothing.

You can conflate per symbol, per client, or both. Per-symbol conflation collapses the firehose upstream. Per-client conflation adapts to the consumer: a fast desktop can take 20 Hz, a struggling mobile connection takes 4 Hz and never falls behind, because you only ever hold one pending value for it. That is the clean way to handle backpressure from slow clients without disconnecting anyone: a slow client simply gets a lower effective sample rate, never a growing queue.

Set a latency budget and a flush cadence

Decide two numbers up front. Your latency budget: how stale is a displayed price allowed to be? For a retail dashboard, 100 to 250 milliseconds is usually invisible and generous. For a pro tool, tighter. Your flush cadence follows from that budget. Latency is a product decision, not a metric you chase to zero. Zero-latency tick-by-tick delivery to a browser is expensive and pointless.

Then send deltas, not full snapshots. A subscriber needs the changed price and size, not the entire watchlist re-serialized every flush. Sending deltas instead of full state keeps payloads tiny when a hundred symbols are moving at once. On subscribe, send one full snapshot so the client has a baseline, then deltas forever after.

Keep the display feed and the trade path separate

The dangerous mistake is running your executable order path over the same conflated stream as your ticker. Never do that. An order acknowledgement, a partial fill, a cancel confirmation: these are exactly-once, ordered, durable events. Route them on a dedicated channel with real delivery guarantees and replay after reconnect, so a dropped socket during a fill does not lose the fill.

This split is a governance boundary as much as a performance one. The trade path needs authorization on every message and a full audit trail. The display path needs speed and can be lossy. Give them different channels, different rules, different guarantees. If you are designing subscriptions, authorize every real-time subscription on the trade path especially, because a viewer of prices is not automatically permitted to see or place orders.

What to look for in the backend

A backend for market data should support server-side conflation, per-client rate adaptation, delta encoding, and per-channel delivery semantics so your ticker and your trade path can coexist without one degrading the other. If you are building this, AltoHost handles the conflation and backpressure mechanics so you are not hand-rolling per-client rate limiters under load. Before you commit, evaluate the real-time backend specifically against a firehose input and a slow-client output, because that is the exact stress a trading feed applies.

The principle is simple and it saves you at scale: a display feed exists to show the freshest value, not every value. Conflate the ticker, protect the trade path, and a thousand ticks a second becomes ten frames a second that a human can actually use. For infrastructure that treats conflation as a first-class primitive, look at AltoHost.