Backpressure and resume

What happens when a client reads too slowly, how to reconnect, and how event channels resume without losing events.

#Reading too slowly

Each connection has its own queue; one slow client never slows another.

• Above 1 MB waiting: state channels (candles, indexes, levels, flow) send only their newest state.
• Above 4 MB: trade and liquidation frames are dropped, each drop announced by a gap frame. Event frames are never dropped.
• Above 8 MB, or above 1 MB for 30 seconds without draining: the connection is closed with 4009 slow_consumer.

Read frames promptly (hand work to a queue), and hold only the channels you use.

#Reconnecting

Reconnect with exponential backoff and jitter: about 0.5 s, 1 s, 2 s, 4 s ... up to 30 s; at once after 1012 (a server restart); never after 4001, 4003 or 4010 (fix the key or scope first). After reconnecting, subscribe again.

#Resuming event channels

Event frames carry event_id. Reconnect and subscribe with the last id you saw per channel:

{"op":"subscribe","id":"r1","channels":["calendar:US"],"resume_from":{"calendar:US":81723}}

Events missed within the last 15 minutes are replayed first ("replay": true), then live frames continue. Delivery is at least once across a resume: dedupe on event_id. For longer gaps, back-fill with REST (/v1/calendar/events).

Market-data channels do not resume: the first frame after subscribing is a fresh snapshot, and REST fills any gap you need.

The SDKs' stream helpers do all of this: backoff, re-subscribe, resume_from from the last event_id seen, and dropping replays already delivered.