Snapshots vs. streams

Two ways to read state from the API. Pick the right one or you'll either burn rate-limit or lag the market.

You want	Use
One snapshot at app boot	Snapshot RPC (ListPairs, GetBook, BalanceService.Get)
Continuous live updates	Streaming RPC (MarketDataService.Subscribe, BalanceService.Subscribe, TxService.SubscribeBlockhash/SubscribeSlots/SubscribeTxStatus)
Historical backfill	HistoricalService.GetTrades / GetCandles

Streaming RPCs are long-lived. Open one, fan it out across your code (see ResilientStream), and let HTTP/2 multiplex the rest of your traffic on the same channel.

Cadence

Snapshots are bucket-counted per IP. Streams are not. Recommended ceilings for snapshot RPCs:

Operation	Suggested cadence
ListPairs	Once at boot, then on schema changes
GetBook (per pair)	Once at boot + once per reconnect
BalanceService.Get	Once at boot + once per reconnect; otherwise use Subscribe
HistoricalService.GetTrades	As needed for backfill

If you find yourself polling above ~1 Hz, switch to a stream.

The boot pattern

For any UI or bot:

1. ListPairs — discover what's tradeable.
2. GetBook for each pair you care about — populate local book.
3. Subscribe to those pairs — apply deltas to the local book.
4. On reconnect, call GetBook again before re-applying stream events — you may have missed deltas in flight.

The same pattern applies to BalanceService (snapshot via Get, deltas via Subscribe) and to TxService.SubscribeTxStatus (no snapshot — just open the stream when you start submitting).

Backoff on rate-limit

RESOURCE_EXHAUSTED means the per-IP bucket emptied. Honour it; do not retry tighter. Suggested policy: exponential backoff starting at 500 ms, capped at 30 s — same schedule the SDK's ResilientStream uses.

Don't poll the same data over two surfaces

Subscribing to MarketDataService.Subscribe for a pair AND polling GetBook for the same pair just doubles your bandwidth. Subscribe for the live deltas and only call GetBook on a fresh boot or after a stream drop.