Design a Live Data Visualizer

Problem statement

Design a live data visualizer: users open dashboards that receive a constant stream of data from external sources such as IoT sensors, application metrics, and event logs, and every chart updates in near real-time for every connected viewer. The problem requires ingesting streaming data from multiple endpoints, performing real-time transformations such as rolling averages, pushing updates to dashboards over WebSocket or an equivalent push channel, and supporting user-defined views and filters.

The trap is to design the charts. The real system is a many-to-many fanout machine with four planes:

1. Ingest plane: millions of sources push or are polled; points must be validated, authenticated, tenant-scoped, and partitioned without loss.
2. Aggregation plane: raw points become per-second, per-minute, and per-hour rollups, computed once and shared by all viewers.
3. Serving plane: hundreds of thousands of concurrent viewers hold live connections; each viewer watches a tiny, different slice of the data.
4. Control plane: dashboards, panels, permissions, API keys, quotas, and alert rules are strongly consistent and rarely change.

Why this problem is distinctive

A request/response API serves one reader at a time. A live visualizer must take one ingested point and make it visible to every viewer whose panel subscribes to it, within about one second, while the same pipeline absorbs a five-times event peak. The multiplier is brutal: 1M points per second in can become tens of millions of outbound messages per second if you naively forward every sample to every viewer. The architecture therefore lives or dies on three decisions: where aggregation happens, how fanout is coalesced to display cadence, and how tenants are isolated from each other.

Public operating baseline

The category is real and large. Grafana Labs describes Grafana Mimir as a time-series database designed to scale to one billion active series in a single cluster, and Grafana itself reports more than 20 million users. Datadog shareholder materials describe a platform processing trillions of monitoring data points per day across more than 28,000 large customers. Uber's engineering blog describes its M3 metrics platform ingesting tens of millions of metrics per second. Cloudflare reports handling more than 50 million HTTP requests per second and serves its real-time dashboards from Kafka and ClickHouse. These are cited company figures, not our design targets.

Explicit design assumptions

Unless a number is attributed to a company above, it is a stated assumption: 1M data points per second average ingest, 5M per second peak, 1M active series, 50,000 concurrently active dashboards, 200,000 concurrent viewers, 200 bytes average raw event, and 1 Hz display cadence after coalescing.

The rest of this answer designs exactly that system.