A team proposes a specialised real-time analytics store for an internal dashboard used by twelve analysts. Assess.

What the interviewer is testing

Whether you know what this category of store is actually for, and whether you will decline additional operational surface.

What the category is for

Real-time analytics stores exist for a specific gap: aggregates over billions of rows, in under a second, at thousands of concurrent users, on data seconds old. That is customer-facing analytics — an embedded dashboard in your product, a usage view for every account, an operational monitoring interface.

The distinguishing question is whether query volume is driven by users or by analysts. Twelve analysts is not a concurrency problem.

Why the warehouse suffices here

Twelve analysts generate negligible concurrent load. The warehouse already holds the data, already has governance and access control, and already has the transformation pipeline.

If dashboard queries are slow, the cheap fixes come first: pre-aggregated tables so the dashboard reads a small summary rather than scanning raw events, result caching, and a partitioning and clustering layout that lets queries prune. Those typically produce sub-second dashboards without any new system.

The costs of the proposal

Another system to operate, scale, patch, secure and back up. A second copy of the data with its own freshness and correctness questions. Denormalisation at ingestion, pushing complexity upstream into the pipeline. Limited or expensive joins. Awkward updates and deletes, which matters for corrections and erasure requests. And a second governance surface.

For twelve analysts, that is a poor trade.

When the answer changes

If this dashboard is later embedded in the product and exposed to every customer, the concurrency profile changes completely and the category becomes appropriate. That is worth saying explicitly, so the decision is understood as scoped rather than as a permanent rejection.

What a strong answer adds

Asking what specifically is slow now, with the query and its plan. "The dashboard is slow" frequently resolves to one unpruned query against an unpartitioned table, which is an afternoon's work rather than a new platform.

Common weak answers

Approving because the technology fits the description. Refusing without offering the cheaper path to the outcome the team wants.