Overview
A dashboard that shows data from this morning is a report. A dashboard that shows what is happening right now — positions updating tick by tick, server metrics refreshing every second, order flow moving in real time, alerts firing the moment a threshold is crossed — is an operational tool. The difference is not cosmetic. It is the difference between information that drives decisions and information that documents history.
Real-time dashboards are technically demanding in ways that static reporting is not. The data delivery infrastructure has to move data from source to screen with minimal latency. The frontend has to update efficiently without re-rendering the entire page on every data change. The backend has to handle many concurrent connections simultaneously without degrading under load. And the whole system has to remain stable and performant when data arrives in bursts, when connections drop and reconnect, and when the number of simultaneous viewers grows.
We design and build real-time dashboards for trading operations, system monitoring, business operations, logistics tracking, and any context where the value of information decays rapidly and decisions depend on seeing current state rather than recent history. The stack centres on Rust for high-performance WebSocket backends capable of handling large numbers of concurrent connections efficiently, React and Next.js for frontends that update smoothly without unnecessary re-renders, and direct integration with whatever data sources the dashboard needs to surface.
What Real-Time Dashboards Are Used For
The use cases for real-time dashboards span every domain where things change faster than a scheduled report can capture:
Trading and market data. Live P&L across open positions updating with every price tick. Order book depth and trade flow for instruments being actively traded. Portfolio exposure across assets, currencies, and risk factors updating in real time. Algo and EA performance monitoring — active trades, drawdown, equity curve — for automated systems running without constant manual supervision. Market data feeds across multiple instruments displayed simultaneously with the latency that trading decisions require.
System and infrastructure monitoring. Server health metrics — CPU, memory, disk, network — across a fleet of hosts displayed on a single surface. Application performance metrics — request rate, error rate, response latency percentiles — updating continuously so that performance degradation is visible the moment it begins. Queue depths, worker throughput, and job processing rates for background processing systems. Alert dashboards that surface anomalies and threshold breaches as they occur rather than after a polling interval.
Business operations. Live order intake across channels during high-volume periods. Real-time inventory levels updating as stock moves through the warehouse. Customer support queue status — open tickets, wait times, agent availability. Sales pipeline movement and conversion metrics updating throughout the trading day. KPIs and operational metrics that management needs to see continuously rather than in morning reports.
Logistics and fulfilment. Shipment status boards showing live delivery progress across an active order pool. Vehicle and driver location tracking for fleet operations. Warehouse throughput — pick rates, packing rates, dispatch volumes — updating in real time for operations management. Carrier API status monitoring showing integration health across logistics providers.
Financial operations. Cash position and liquidity monitoring updating throughout the banking day. Transaction processing volumes and error rates. Reconciliation status boards showing matching progress across large transaction sets. Regulatory reporting deadline tracking with live progress indicators.
The Technical Architecture of Real-Time Dashboards
Real-time data delivery to browser clients is solved through WebSocket connections that maintain a persistent bidirectional channel between the server and each connected client. Unlike HTTP polling — where the client repeatedly asks the server for new data on a schedule — WebSocket allows the server to push data to clients the moment it is available, eliminating the latency of the polling interval and the overhead of repeated HTTP request cycles.
Rust WebSocket Backend The WebSocket server is the core infrastructure component of a real-time dashboard. It accepts connections from browser clients, subscribes those connections to the data streams they need, receives data from upstream sources, and pushes it to the relevant connected clients as it arrives.
We build WebSocket backends in Rust using Axum because the performance characteristics of Rust at this layer matter significantly. A WebSocket server handling thousands of concurrent connections needs to manage connection state efficiently, route incoming data to the correct subscribers with minimal overhead, and push outbound messages without the latency spikes that garbage collector pauses introduce in managed-runtime alternatives. Rust's async runtime — Tokio — handles concurrent connections without the per-thread overhead of blocking I/O models, allowing a single server instance to handle connection volumes that would require significant horizontal scaling with heavier runtimes.
The WebSocket backend is responsible for connection lifecycle management — accepting connections, authenticating them, tracking which clients are subscribed to which data streams, managing reconnection when clients drop and reestablish, and cleaning up state when connections close. It is also responsible for fan-out — taking a single incoming data event and delivering it to all clients that have subscribed to that data stream, efficiently and without head-of-line blocking between slow and fast clients.
Data Source Integration A real-time dashboard is only as good as the data it surfaces. Data arrives from different sources depending on the domain:
Exchange and broker WebSocket feeds for market data — connected to upstream WebSocket APIs that deliver price updates, order book changes, and trade records, with the dashboard backend maintaining the upstream connections, normalising the data, and distributing it to connected dashboard clients.
Database change streams and polling for operational data — applications that write state changes to a database can be monitored through change data capture or efficient polling, with updates distributed to dashboard clients as changes occur.
Internal application event streams for system metrics and operational data — applications publishing events to message queues or internal pub/sub infrastructure, with the dashboard backend subscribing and distributing.
External REST APIs polled at appropriate intervals for data sources that do not support push — with the polling managed server-side so that many dashboard clients share a single upstream connection rather than each polling independently.
Pub/Sub and Fan-Out Architecture When the number of connected clients is large or when the dashboard is deployed across multiple server instances for horizontal scaling, a pub/sub layer between data sources and the WebSocket server coordinates message distribution. Redis Pub/Sub provides the message bus that allows multiple WebSocket server instances to receive data events and deliver them to whichever instance holds each client's connection — enabling horizontal scaling of the WebSocket layer without requiring all clients to be connected to the same instance.
React Frontend The frontend of a real-time dashboard has specific performance requirements that general React development does not always encounter. When data updates arrive many times per second across many displayed values simultaneously, naive React rendering — re-rendering the entire component tree on every update — produces visible jank that makes the dashboard uncomfortable to use.
We build real-time dashboard frontends with explicit attention to render performance:
State management that isolates updates to the components that display the changed data, preventing unrelated components from re-rendering when a value they do not display changes. Memoisation of expensive computations and component renders that do not need to recalculate on every update. Virtualised lists for dashboards displaying large numbers of rows — rendering only the visible rows rather than instantiating DOM elements for every record in the dataset. Canvas or WebGL rendering for high-frequency chart updates where SVG or DOM-based charts cannot maintain smooth animation at the required update rate.
WebSocket connection management on the client handles reconnection automatically — establishing a new connection when the previous one drops, resubscribing to data streams, and displaying appropriate status to the user during disconnected periods rather than silently showing stale data.
Charting and Visualisation
Real-time dashboards often require charting that updates continuously rather than rendering a static snapshot. The right charting approach depends on the update frequency and the chart type:
Time series charts that append new data points as they arrive — candlestick and line charts for price data, area charts for metric history, bar charts for volume. At low update frequencies, standard charting libraries handle continuous updates well. At high update frequencies — multiple updates per second on charts with many data points — canvas-based rendering is necessary to maintain smooth animation without overwhelming the browser's rendering pipeline.
Gauge and indicator visualisations for single-value metrics that need to be immediately scannable — current P&L, system health status, utilisation percentages, threshold proximity indicators. These are designed for fast perception, not detailed analysis.
Data tables with live updates for dashboards displaying tabular operational data — order lists, position tables, monitoring grids — that update individual cell values as data changes rather than refreshing the entire table.
Heat maps and matrix visualisations for correlation data, market breadth, multi-asset exposure, and other multi-dimensional data that needs to be displayed compactly and updated continuously.
Alert and notification surfaces that draw attention to threshold breaches, anomalies, and conditions that require immediate action — with visual and optionally audio signalling that is distinct from the ambient information display.
Alerting and Threshold Monitoring
A real-time dashboard that displays data but does not alert when important thresholds are crossed requires constant human attention to be useful as a monitoring tool. Alerting logic built into the dashboard infrastructure — evaluated server-side against the live data stream — surfaces important conditions without requiring someone to be watching the display at the exact moment they occur.
We build alerting infrastructure that evaluates configurable conditions against the live data stream — price thresholds, metric anomalies, status changes, rate-of-change alerts — and delivers notifications through the dashboard UI, and optionally through external channels including Slack, email, or SMS via Twilio, when conditions are met.
Alert configuration is managed through the dashboard interface rather than requiring code changes — users can define their own thresholds, set notification preferences, and manage alert history through the dashboard itself.
Authentication and Access Control
Real-time dashboards frequently surface sensitive operational data — trading positions, financial metrics, system credentials, business KPIs — that should not be accessible to everyone. Authentication and access control are built into the WebSocket infrastructure:
Connection authentication validates that each connecting client presents a valid identity token before accepting the WebSocket connection and subscribing them to data streams. Tokens are validated on connection establishment and re-validated on reconnection — a token that expires or is revoked closes the connection and prevents reconnection without fresh authentication.
Data stream access control ensures that connected clients only receive data they are authorised to see — a user with access to their own account's data does not receive data for other accounts, a user with read-only access cannot trigger actions through the WebSocket connection, and per-role data filtering applies the same access rules to real-time data that the REST API applies to historical data.
Performance Under Load
Real-time dashboards face performance challenges that other web applications do not. A trading dashboard during a volatile market session may need to process thousands of price updates per second across hundreds of connected clients. A system monitoring dashboard during an incident may have many more concurrent viewers than during normal operations.
We validate real-time dashboard performance under realistic load conditions before deployment:
Connection load testing establishes how many concurrent connections the WebSocket backend handles at acceptable latency — and where the limits are so that horizontal scaling can be planned before those limits are reached in production.
Message throughput testing validates that high-frequency data delivery — many messages per second across many connected clients — does not cause message queuing or delivery latency that makes the dashboard data meaningfully stale.
Frontend performance profiling under high update rates validates that the React rendering pipeline maintains smooth UI updates without frame drops when many values are updating simultaneously.
Technologies Used
- Rust / Axum — high-performance WebSocket server, concurrent connection management, data fan-out
- React / Next.js — dashboard frontend, component-level state management, optimised real-time rendering
- TypeScript — type-safe frontend and API code throughout
- Redis Pub/Sub — message distribution across horizontally scaled WebSocket server instances
- WebSocket / Server-Sent Events — real-time data delivery protocols
- SQL (PostgreSQL, MySQL) — historical data storage, alert configuration persistence
- REST — data source integration for sources without native push support
- Auth0 / JWT / OAuth2 — WebSocket connection authentication and access control
- Recharts / Canvas / WebGL — frontend charting appropriate to update frequency and complexity
- Slack / Twilio / Email — external alert delivery channels
Building Your Real-Time Dashboard
Real-time dashboards have specific technical requirements that general web development experience does not necessarily cover. The WebSocket infrastructure, the render performance work, the connection management, the fan-out architecture, and the load characteristics all require deliberate design rather than emerging from standard web application patterns.
We have built real-time dashboards for trading operations monitoring live market positions, for infrastructure teams monitoring distributed system health, for ecommerce operations tracking live order flow, and for financial operations monitoring transaction processing in real time. The technical foundations are consistent across these domains even when the displayed data is completely different.