Managing Trade State with WebSockets in a Crypto Exchange
Lessons from building live price feeds and order state on arz.me — without over-engineering.
By Hossein Khalili · 2 min read
Building a crypto exchange front-end means living inside two timelines: what the server last confirmed, and what the market is doing right now.
On arz.me, live prices arrive over WebSocket while order state still has to respect REST confirmations. The mistake I see often is merging those into one giant store on day one.
Separate concerns early
- Market stream — ephemeral, high frequency, safe to drop stale ticks
- Order book / user orders — authoritative only after API confirmation
- UI chrome — connection status, reconnection backoff, last updated timestamps
Keeping the market stream in its own module (even a simple Zustand slice or isolated Redux reducer) prevents trade actions from re-rendering on every tick.
Reconnection is a product feature
Users notice disconnects during volatility. Show state clearly:
- Connected — normal UI
- Reconnecting — disable submit, keep last prices visible with a stale badge
- Offline — block new orders, explain why
Do not over-subscribe
Subscribe only to symbols the user is viewing. Unsubscribe on route change. This sounds obvious until every panel inherits a global socket singleton dumping 200 symbols into React.
Takeaway
WebSocket is not a replacement for REST — it is a parallel channel with different consistency rules. Design state boundaries around that and the UI stays predictable even when the market is not.