Skip to content

ADR-PROTO-005: Hybrid in-prototype (some metrics from Postgres, some from Databricks)

Status: Accepted Source: prd-v2.1.md §C.8

Context

Asurion's data engineer can provide real data for 2–3 metrics in the prototype timeframe. Building real Databricks routing for all 10+ metrics is out of scope.

Decision

Per-metric routing via config/metric_routing.yaml. 2–3 selected metrics route to Databricks; the rest continue reading from Postgres seed data unchanged. The mixed routing is the demo narrative — proves the platform routes per-metric to the right backend.

A boot-time validator at backend/app/sql_gen/routing.py (validate_routing_against_catalog) raises RuntimeError for any metrics_catalog.name without a routing entry — fail-loud, mirroring ADR-008.

Consequences

  • The demo shows BOTH paths working, which is more credible than picking one.
  • Adding a new Databricks metric is a config change + a metrics_catalog lineage update (no code).
  • Risk: if all 2–3 selected metrics happen to query the same table, the demo doesn't show breadth — the three selected metrics (claim_volume_l3_asurion, claims_by_product_l3_asurion, claim_status_mix_l3_asurion) all hit l3_asurion.ev_claim with different aggregations, which is a deliberate choice to keep the seeder small while still showing single-value/grouped/distribution shapes.
  • Validates the §B.5.5 routing principle ("Postgres for what's happening now; Databricks for what to learn from it") concretely.

Cross-references