A stream’s effective cost is a function of symbol count, channel count, venue activity, replay speed, and downstream processing. Start with one symbol and one channel, then widen only after the consumer can keep up without message drops. If a replay job is meant to produce research output, record the window, speed, channel list, and gap events with the resulting file.
Retry budget, reconnect backoff, resubscribe list, gap response, and rebuild path
Stop trigger
Lag threshold, gap state, storage failure, auth failure, or data-quality failure
The packet keeps a limit request tied to the client that has to consume the messages. A higher plan limit does not fix a consumer that drops messages or cannot write replay output in order.
Clients should protect themselves from message bursts. Use bounded queues, drop or pause noncritical UI updates when necessary, and stop replay rather than letting memory grow without limit. A replay that cannot be consumed in order is not a trustworthy replay.
Account limits can affect both REST and WebSocket use. If a workflow mixes REST preflights, WebSocket replay, and SDK reconstruction, budget them as one job instead of independent scripts. Pair this page with Rate Limits and Data Quality before deploying shared tooling.
Before raising subscription count or replay speed, verify consumer lag. A WebSocket job that receives data faster than it can process will eventually produce stale UI state, dropped messages, or incorrect local books.Limit decisions should be documented near the consumer, not hidden in a connection helper.Track replay speed separately from live subscription count.They stress different parts of the client.Live subscriptions stress steady-state consumers. Replay stresses backlog, ordering, storage, and gap handling. Size and observe them separately.
