Rebuild materialized views without serving internally inconsistent fiction

• Define whether users require point-in-time consistency across widgets or only per-entity freshness. Identify source-of-truth tables, event-log retention, rebuild duration, and acceptable visible staleness.

• Assume five billion derived rows, 50k source changes/second, and a rebuild lasting days. Estimate storage for parallel view versions and ensure the delta log remains available until every range catches up.

• Never mix incompatible view schemas in one response, publish a complete version atomically at a defined source position, and expose freshness. The old view remains serviceable until the new one is proven.

• Create a versioned view namespace. Build from a consistent snapshot at position L, apply changes after L into the new version, validate by partition, then atomically move a routing pointer once global readiness criteria pass.

• Backfill stable key ranges with source position and transform version, while a delta consumer upserts idempotently. Per-range watermarks and checksums let the controller know which partitions are complete and caught up.

• A request reads one declared view version and its watermark. Multi-widget responses pin that version; monotonic routing prevents a user bouncing from new back to old except during an explicit rollback.

• Failed partitions retry from checkpoints, schema-poison events quarantine with visible gaps, and a lagging range blocks only publication. If post-cutover errors appear, move the pointer back while the old view remains current through dual consumption.

• Apply row and tenant filters during both snapshot and stream paths, and validate that transformed fields do not broaden access. Temporary parallel stores inherit encryption, retention, and deletion requirements.

• Measure range completion, delta lag, checksum and aggregate differences, query-result shadow comparisons, freshness, and version adoption. Users and support should see the data-as-of timestamp.

• Parallel versions can double storage and write amplification, so budget the overlap and clean only after rollback expiry. Throttle source scans and isolate rebuild compute from serving capacity.

• In-place mutation saves storage but makes mixed-schema results unavoidable. Versioned rebuilds cost temporary duplication but provide a clean publication and rollback boundary.

• Ship readers that understand version metadata before creating the new view. Shadow reads, compare aggregates and selected entities, canary internal users, then flip cohorts and finally the global pointer.

• The core is a shared source position across snapshot and stream plus an atomic version switch. Strong candidates discuss user-visible freshness, cross-widget pinning, validation, and old-view maintenance during rollback.

Interviewer evaluation rubric