Serving advertiser dashboards to thousands of partners at once

A reporting dashboard is the central real-time analytics product for advertisers across the digital advertising ecosystem. It acts as the  main control hub they interact with daily. In most stacks, the underlying architecture supporting it is designed for a different audience entirely: a dozen internal analysts running heavy queries occasionally, rather than thousands of customers running small ones at the same moment.

99% of the time, this architecture is built using a data warehouse. Warehouses are optimized for a small number of large, scan-heavy queries supporting those dozen of internal analysts. 

The  thousands of customers running concurrent, small, filtered aggregations on the other hand, don’t have the same foundational support. Instead, the queries they expect to respond in a matter of seconds lead to queuing and throttling warehouses. 

AdTech platforms then look to alternative ways like scaling compute, but the architecture doesn’t remove the underlying root problem of costs. It only chooses who pays for it.

Let’s explore this further and see how to address it.

The Monday morning concurrency spike

Advertiser activity across agencies, platforms, and ad networks tends to concentrate around predictable, high-traffic moments. . What this looks like is budget resets, campaign reviews, and quarterly reporting all happening simultaneously across agencies resulting in login volume and query concurrency spiking to several times the weekday average in under an hour. 

In a warehouse, this surge drives utilization to a tipping point where queues form and query latency jump from two seconds to thirty. In other words, this performance degradation affects the largest spenders at the exact moment they are preparing high-stakes commitment decks!

The limitations of the caching mitigation stack

The standard response to dashboard latency is building a familiar stack: BI extracts, cache layers, and pre-aggregated rollup tables. Engineers often favor this path because the natural instinct is to maximize existing tools rather than introduce a new system. This cycle continues until every combination of caches and rollups is exhausted.

Only then is an alternative sought. 

Each of these additional layers  swaps the latency issue for a new one, data staleness. That’s another problem we discuss  further in the initial post.

In a real-time analytics environment of continuous streaming, cache invalidation failures create the most damaging artifact in client-facing analytics: the metric that moves backward upon refresh. While a slow response is interpreted as high load, a retreating number signals to the customer that the dashboard is unreliable, leading to aloss of trust that is both permanent and can resurface during  billing disputes.

Pre-aggregation also imposes a significant cost on the product roadmap. By freezing the set of queries that can be answered efficiently, rollups turn simple requests for new breakdowns into pipeline tickets requiring sprint estimates. The platforms most dependent on pre-aggregation inevitably experience the slowest product evolution (though this cost is rarely acknowledged because it is paid in features that are never developed).

The True Cost of Concurrency in Consumption Models

While the cost of a single query might seem negligible, the cumulative effect of concurrency under consumption pricing is anything but. When multiplied across an entire client base, these small costs skyrocket where the expense of delivering analytics scales exponentially in user growth. 

Because AdTech loads are inherently spiky, the required capacity often scales even more aggressively than the customer count. Every new partner adds concurrent strain to the shared infrastructure, further steepening the cost curve. 

If a reporting product's gross margin deteriorates as its adoption increases, the issue isn't all about pricing. Instead, it’s a structural  failure cascading as a financial one. Attempting to solve this by renegotiating warehouse contracts merely addresses the symptom while leaving the underlying cause untouched.

Architectural Transformation via a Unified Serving Layer

The solution lies in augmenting the existing data platform with  a real-time analytics engine purpose-built for these types of workloads: one such as SingleStore. SingleStore handles massive volumes of filtered, aggregate queries against data that arrived only seconds ago, all while maintaining flat latency under heavy concurrency. 

By caching common query plans using its patented Universal Storage, the engine can manage multiple point lookups and aggregations from one place. Serving dashboards directly from the ingestion point eliminates the staleness window identified in the freshness analysis and removes the need for the external caching and additional layers that cause data drift.

It’s important to note that the serving layer is an augmentation of the existing warehouse, not a replacement for it. Deep, historical exploration and heavy back-end analytics remain the specialty of the warehouse. The boundary is centered on the distinction between two workload profiles: (1) concurrent, latency-sensitive, customer-facing tasks, and (2) occasional, scan-intensive, exploratory research on the other. A modern architecture assigns each to the engine best equipped for the job.

Evaluating the margin impact

While a warehouse can theoretically serve advertiser dashboards if provided with sufficient compute, the real concern is the impact on gross margins due to the ongoing engineering cost of maintenance. Most platforms only confront the limitations of this architecture at renewal time. At that point,  the suboptimal infrastructure has been overloaded for years.

At the same time, dashboards are no longer the sole consumers of the serving path. The rise of models and agents introduces a second concurrent audience with unpredictable query patterns and an absolute requirement for speed.  The next post in this series explores what these AI-driven clients require from the data layer.