01.Why polling does not work
A REST poll gives you a snapshot at the moment you asked. To notice a fast move you have to ask constantly, which burns rate limit and still leaves you a poll interval behind. Every trader doing the same thing arrives after the ones who are streaming. For display-only dashboards refreshing on a slow cadence this may be acceptable; for anything that trades, it is not.
- Polling cost scales with how fresh you need the data to be.
- You are always at least one interval behind a streaming participant.
- Rate limits bind well before you reach useful freshness.
02.What to subscribe to
Subscriptions are scoped, so ask only for what you use. A bot watching five markets should not subscribe to everything — the extra traffic costs you parsing time on the hot path and gains nothing. Decide up front whether you need full book depth or only top-of-book, because that choice drives your message volume more than the number of markets does.
- Subscribe per market rather than firehosing everything.
- Top-of-book is far lighter than full depth; take it if it is enough.
- Trade events and book updates are separate concerns — handle them separately.
03.Reconnecting without losing your place
The connection will drop. Networks fail, deploys restart processes, and providers reset connections. The failure mode that costs money is a bot that keeps trading against a stale in-memory book after the socket quietly died. Treat reconnection as a first-class path, not an error case: on reconnect, discard local state and refetch a fresh snapshot before acting on anything.
- Reconnect with exponential backoff rather than a tight retry loop.
- Discard the in-memory book on reconnect; never merge into stale state.
- Refetch a REST snapshot to re-seed, then resume applying deltas.
- Use a heartbeat and treat silence as a disconnect — a hung socket looks alive.
04.Keeping a local book correct
Streaming gives you deltas, and applying deltas to a book you seeded incorrectly produces a book that is wrong in ways you will not notice until it costs you. Seed from a REST snapshot, apply updates in order, and if you ever detect a gap in sequence, resynchronise from scratch rather than patching. A bot that trades from a subtly wrong book is worse than one that stops.
- Seed from a snapshot, then apply updates strictly in order.
- On any sequence gap, resync completely rather than repairing.
- Log and alert on resyncs — frequent ones mean something upstream is wrong.