Propose a technical architecture for a centralized Metrics Layer or Metrics Store

WHAT THIS TESTS: The interviewer wants to know if you understand that metric inconsistency is an architecture problem, not a documentation problem. They are looking for familiarity with the semantic layer pattern: moving metric definitions out of individual dashboards, notebooks, and ETL scripts into a governed, versioned system that serves as the single source of truth for business logic.

A GOOD ANSWER COVERS: First, a metric registry or semantic layer where definitions like active user are declared as code, stored in git, and owned by data engineering or analytics engineering. Second, a query planner or API tier that sits between BI tools and the data warehouse, translating high level metric requests into optimized SQL or OLAP queries against raw or modeled tables. Third, a caching or materialization strategy, such as precomputed aggregates or a cube service, so the layer does not add unacceptable latency at scale. Fourth, governance and access controls, including breaking change review, deprecation policies, and discoverability via a data catalog, so teams cannot bypass the layer.

COMMON WRONG ANSWERS: Proposing a single shared database view or a wiki page with the definition. Views lack versioning and governance, and teams still copy SQL into local scripts. Suggesting a data lakehouse alone without a semantic abstraction. Recommending a heavyweight monolithic ETL rewrite instead of an incremental API layer. Ignoring performance and suggesting on the fly joins across petabytes of raw event data for every dashboard query.

LIKELY FOLLOW-UPS: How would you handle a breaking change to the active user definition when fifty dashboards depend on it? How do you enforce that teams route through the metrics layer instead of writing direct warehouse queries? What is your rollout strategy: do you materialize metrics eagerly or compute them lazily? How do you reconcile real time streaming metrics with batch historical metrics in the same layer?

ONE CONCRETE EXAMPLE: Imagine three teams define active user differently: product counts unique device IDs in the last thirty days, finance counts paying users with revenue in the last thirty days, and marketing counts anyone who opened an email. In the metrics layer, each definition is a named, versioned entity in the registry: active_user_product_v2, active_user_finance_v1, and active_user_marketing_v1. A product manager queries active_user_product_v2 through the metrics API. The query planner maps this to a precomputed aggregate table refreshed daily, or falls back to a SQL template joining events and devices. When product wants to change the window to seven days, they open a pull request, the data team reviews downstream impact via lineage metadata, and the API begins serving v3 while v2 is deprecated with a sunset date. No team rewrites SQL in Looker, Tableau, or Jupyter.