Building a WebSocket-Driven State Layer for Real-Time Trading UIs

Overview

Real-time trading interfaces live or die on perceived latency. When a price tick or order update takes too long to reach the screen, traders lose trust in the product — even if the underlying execution was correct. This post walks through the state architecture that kept a trading UI feeling instant.

The Problem

Mixing websocket-driven market data with React component state meant every tick triggered cascading re-renders across the order book, position table, and chart — even components that had nothing to do with the field that changed. Under real trading volume, the UI would visibly stutter.

The Approach

The fix was a normalized store for order-book and position data, kept entirely separate from UI state, with components subscribing to narrow slices instead of the whole feed. React Query handled REST fallback for anything the socket hadn't delivered yet, and position tables were virtualized so large books didn't pay a rendering tax they didn't need to.

Key Takeaways

Websocket state deserves its own store, separate from UI state — mixing them is where most trading-UI performance bugs come from. Optimistic UI on top of that store has to reconcile loudly against on-chain confirmations, not silently, especially in a financial context where being wrong is expensive.