How a Scalable Data Dashboard Handles 500+ Real-Time Screens with Millisecond Latency

Background

What is a data big screen? A data big screen is an electronic display used for real‑time visualization and monitoring of large volumes of data, typically deployed in large conference rooms, command centers, exhibition halls, or data centers. It aggregates multiple data sources to provide decision‑makers with clear analytical results and key metrics.

Usage statistics – The platform has been adopted by more than a dozen departments within the group, with over 2,000 screens in operation. During peak periods, the system supports approximately 300 concurrent screens in the summer‑autumn cycle and about 500 concurrent screens in the winter‑spring cycle.

Technical Architecture

Functional matrix – Core features include dashboards, data big screens, self‑service downloads, metric management, push management, bot management, and AI analysis.

Service structure – Designed for high availability and scalability, the system is decomposed into platform, metric, engine, push, AI, algorithm, upload, and screenshot services.

Technology stack – Vue, NodeJS, Echart, Spring, MQ, Redis, and various OLAP databases (ADB, Hologres, MySQL, StarRocks, Hive) running on a dual‑active Tencent Cloud + Century Internet K8s container environment.

The data flow follows a full‑link pipeline: source data is collected, cleaned, transformed, modeled, loaded, securely stored, and finally presented via dashboards or big screens.

Core Technical Implementation

High‑concurrency solution – Horizontal scaling by adding compute nodes, vertical scaling to increase per‑node throughput, and overall stability guarantees for long‑running reliability.

Caching workflow – Proactive caching pre‑loads data to reduce OLAP pressure. Dynamic hotspot caching uses an LRU algorithm for top‑10 hot items, while access‑frequency ranking tracks request counts to prioritize cache entries.

Access‑frequency ranking – Two approaches: (1) select the latest 10 uploaded items and increment their counters on access; (2) maintain a cache of 20 items, periodically evicting the lowest‑frequency entries and keeping the top‑10.

Resource isolation – Namespace‑based isolation in K8s containers, dynamic configuration via Nacos, and elastic scaling to prevent resource contention across business lines.

Performance testing – OLAP stress tests simulate query loads using scripts, while end‑to‑end tests cover authentication, permissions, and scheduling. Tools include wrk and the internal PTS platform.

Monitoring – Real‑time alerts for query traffic, PV counts, and resource thresholds; AOP‑based timeout detection for database, cache, and service calls; service‑wall alerts for metric breaches.

Conclusion

The data‑screen system successfully supports over 500 concurrent screens during peak periods, achieves a cache hit rate of 93%, reduces OLAP engine CPU usage to a maximum of 10%, and records zero production‑environment alarms.

Future work will focus on further improving real‑time performance, stability, and intelligent capabilities to provide deeper data support for business decisions.