30% offEnding soon
FSD-024Frontend system design Premium

Design a Real-Time Analytics Dashboard

Design a real-time analytics dashboard with ordered updates, event-time windows, backpressure, synchronized panels, reconnection, and accessible rendering.

Advanced 58 min read

A real-time analytics dashboard is a versioned projection of server-computed metric windows. A snapshot establishes the base. Ordered patches advance it. Sequence gaps pause mutation. Late data replaces a known window revision. The browser publishes at a bounded cadence instead of repainting for every network message.

The word “real-time” hides several clocks. An event happens at the source, a stream processor closes or revises its window, a gateway sends an update, the browser receives it, and a chart eventually paints it. Showing the current receipt time next to an old event-time window does not make the data fresh.

The frontend needs a canonical subscription, snapshot-plus-patch protocol, contiguous sequence ledger, reconnect cursor, event-time metadata, bounded transport queue, coalesced render store, synchronized interaction state, and explicit stale states. The service owns authorization and aggregate truth.

Clarify the operational promise

Ask what “real-time” means for this product: expected source-to-screen delay, supported lateness, correction policy, update volume, metric cardinality, number of panels, filters, history range, offline behavior, exports, alerts, tenant boundaries, and accessible alternatives.

For this interview, assume an authenticated operations dashboard with KPI cards, time-series charts, categorical breakdowns, and a detail table. The service emits aggregate snapshots and patches for one canonical filter scope. Windows use event time and may receive late corrections. The dashboard supports reconnect/resume, cross-panel hover and selection, a paused historical mode, freshness indicators, and responsive layouts.

Raw event exploration, alert-rule authoring, stream-processing implementation, and arbitrary dashboard composition are separate products.

The public interview prompt

Design a reusable real-time analytics dashboard. Explain:

  • metric identity, units, delta versus cumulative temporality, event-time windows, watermarks, and late corrections;
  • snapshot, patch, sequence, cursor, replay, resnapshot, duplicate, and gap contracts;
  • SSE versus WebSocket, reconnect policy, heartbeat, backpressure, hidden tabs, and offline states;
  • canonical filters, subscription generations, caches, server authorization, and high-cardinality limits;
  • normalized metric storage, chart synchronization, selection, brush ranges, history mode, and URL state;
  • transport cadence versus paint cadence, workers, coalescing, downsampling, and rendering budgets;
  • freshness, provisional and final windows, accessibility, internationalization, testing, telemetry, and rollout;
  • failure modes, rejected approaches, staff-level trade-offs, and interviewer follow-ups.

What the premium solution covers

The complete solution defines a semantic metric catalog, canonical subscription key, snapshot-plus-patch envelope, sequence ledger, replay and resnapshot policy, typed window identity, late-correction merge, two-stage buffering model, synchronized panel store, freshness calculation, and production rollout.

Original media follows a dashboard through a sequence gap and recovery, separates the system's three clocks, explains transport versus paint budgets, and marks the browser/service trust boundary. Two deterministic labs exercise stream ownership and render backpressure.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

Should a real-time dashboard receive raw events in the browser?
Usually no. Send authorized, bounded aggregate snapshots and patches. Raw business events increase bandwidth, privacy exposure, memory use, and client-side correctness work.
What is the difference between event time and arrival time?
Event time records when the source event happened. Arrival time records when a service or browser received it. Late and out-of-order events make the distinction essential for correct windows.
How does a dashboard recover after missing a stream message?
Detect the sequence gap, stop applying later patches, and request bounded replay from the last accepted cursor. If replay is unavailable or too large, fetch a fresh snapshot.
How should a hidden dashboard tab behave?
Reduce or pause painting, keep only bounded resumable state, and reconcile through a cursor or snapshot when visible again. Page visibility is a scheduling hint, not an authorization signal.
How are late corrections shown?
Replace the identified metric window with a higher revision and expose provisional versus final state where it matters. Never add a corrected aggregate as if it were a new delta.
When should a dashboard use WebSocket instead of server-sent events?
SSE is a good fit for mostly server-to-client updates over HTTP. WebSocket fits frequent two-way control messages. Either transport still needs sequence, resume, backpressure, and snapshot contracts.