Skip to main content

Optimize WebSocket connection performance

  1. Open the fewest connections that can still serve the workflow.
  2. Subscribe only to the feeds and filters the client actually needs.
  3. Process messages in connection order and keep reconnect state explicit.
  4. Avoid control-plane churn that creates avoidable WebSocket pressure.
  5. Reconcile after reconnect instead of assuming the socket stayed perfect.

Start with subscription shape, not micro-optimizations

  1. Pick the exact feeds needed for the workflow.
  2. Filter by symbol, trader, strategy, or reason wherever the feed supports it.
  3. Keep market-data and user-data consumption logically separate, even if they share one connection.
  4. Use REST for initial snapshots so the WebSocket can focus on live updates.

Preserve ordering guarantees

  • apply updates in top-level ordinal order per connection
  • use globalOrdinal only within one update family
  • use orderMatchOrdinal plus per-order ordinal to reconstruct multi-outcome matches
  • do not merge unrelated connection streams without a clear ordering model

Reduce WebSocket overhead

  1. Avoid repeated subscribe and unsubscribe loops for short-lived views.
  2. Keep callbacks lightweight and hand off heavy processing to a separate queue or worker stage.
  3. Reuse one durable connection where possible instead of opening many competing sockets.
  4. Monitor heartbeat and acknowledgement health so a degraded connection is detected before the state model drifts badly.

Reconnect the same way every time

  1. Store the active subscription set.
  2. Re-open the connection.
  3. Resubscribe in a controlled order.
  4. Resume one update family with its own globalOrdinal.
  5. Run REST reconciliation for any state that must be exact.

Boundary rule

This page explains how to make the public WebSocket path efficient and reliable. It does not publish a guaranteed numeric WebSocket quota or private feed-handling implementation details.

Next routes

Last modified on April 13, 2026