Building Real-Time Trading Dashboards with Spring Boot and WebSockets

Real-time data is the backbone of modern fintech applications. Whether you are building a portfolio tracker, a trading terminal, or a market surveillance tool, the ability to push live data to the client with minimal latency is non-negotiable.

In this post, I walk through the architecture and key implementation decisions behind a real-time trading dashboard built with Spring Boot on the backend and React on the frontend, connected via WebSockets.

Why WebSockets Over REST Polling?

Traditional REST polling introduces unnecessary overhead when data changes frequently. A typical market data feed updates multiple times per second. Polling every 500ms means:

• Wasted requests when nothing changed
• Missed updates between poll intervals
• Higher server load from constant HTTP handshakes

WebSockets solve this by maintaining a persistent, bidirectional connection. The server pushes data the moment it arrives, and the client receives it with sub-100ms latency.

Architecture Overview

The system follows a three-layer architecture:

1. Data Ingestion Layer — Connects to market data providers (REST APIs, FIX protocol, or WebSocket feeds) and normalizes incoming data.
2. Processing Layer — Spring Boot service that applies business logic: aggregations, alerts, portfolio calculations, and risk metrics.
3. Delivery Layer — STOMP over WebSocket connections to push processed data to connected clients.

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        config.enableSimpleBroker("/topic");
        config.setApplicationDestinationPrefixes("/app");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws")
                .setAllowedOriginPatterns("*")
                .withSockJS();
    }
}

Key Implementation Decisions

1. Message Throttling

Not every tick needs to reach the UI. Sending 50 updates per second for a single instrument overwhelms the browser. We implement server-side throttling:

• Snapshot mode: Send full state every 1 second
• Delta mode: Send only changed fields between snapshots
• Priority queuing: Critical alerts bypass throttling

2. Connection Resilience

Network interruptions are inevitable. The client must handle reconnection gracefully:

• Automatic reconnect with exponential backoff
• State reconciliation on reconnect (request full snapshot)
• Visual indicator showing connection status

3. Backpressure Handling

When the client cannot process messages fast enough, the server must not blindly queue them. We use a bounded queue per session with a drop-oldest strategy for non-critical updates.

Frontend: React with Efficient Rendering

On the React side, the challenge is rendering high-frequency updates without dropping frames. Key patterns:

• Virtualized lists for instrument tables (only render visible rows)
• RequestAnimationFrame batching to coalesce updates within a single frame
• Memoization to prevent re-renders of unchanged components

const usePriceStream = (symbol: string) => {
  const [price, setPrice] = useState<PriceData | null>(null);
  const stompClient = useRef<Client | null>(null);

  useEffect(() => {
    const client = new Client({
      brokerURL: 'ws://localhost:8080/ws',
      onConnect: () => {
        client.subscribe(`/topic/prices/${symbol}`, (message) => {
          setPrice(JSON.parse(message.body));
        });
      },
      reconnectDelay: 5000,
    });

    client.activate();
    stompClient.current = client;

    return () => { client.deactivate(); };
  }, [symbol]);

  return price;
};

Performance Results

In a production environment serving 200+ concurrent users tracking 500 instruments:

• Average latency: 45ms from data source to UI
• 99th percentile: 120ms
• Memory footprint: ~180MB JVM heap for the Spring Boot service
• WebSocket connections: Stable at 200+ with no degradation

When to Use This Pattern

This architecture is well-suited for:

• Trading platforms requiring sub-second updates
• Portfolio dashboards with live P&L calculations
• Market surveillance systems with real-time alerts
• Crypto exchanges displaying live order books

For applications where data changes less frequently (e.g., once per minute), traditional REST with caching may be simpler and more appropriate.

Conclusion

Building real-time fintech applications requires careful consideration of data flow, connection management, and rendering performance. Spring Boot with WebSockets provides a robust foundation, but the devil is in the details: throttling, backpressure, and reconnection logic make the difference between a demo and a production system.

If you are building a fintech platform and need help with real-time architecture, get in touch to discuss your project requirements.