## Design a Snapshot-Driven Product Catalog Design a product catalog system with four capabilities: 1. A retailer periodically supplies a complete snapshot used to update its catalog. 2. A shopper can list products. 3. A shopper can view one product's details. 4. An administrator can override selected product attributes. Do not assume scale, snapshot frequency, freshness targets, or override semantics. Identify the values and policies that materially affect the design. ### Part 1 — Define the Catalog and Override Contract Specify retailer, product, snapshot, and override identities. Define how a complete snapshot treats products omitted from the new version and whether an override replaces, masks, or augments the retailer value. #### What This Part Should Cover - Stable identities and an immutable snapshot version. - Explicit omission and deletion semantics. - Override precedence without destroying the imported value. ```hint Preserve both sources of truth If an override overwrites the imported value in place, a later snapshot cannot be reconciled or explained reliably. ``` ### Part 2 — Ingest and Publish a Snapshot Design upload, validation, deduplication, staging, reconciliation, and atomic publication. A bad or partial snapshot must not leave shoppers observing a catalog assembled from two versions. #### What This Part Should Cover - Idempotent delivery and durable raw-input retention. - Schema, duplicate, count, and change validation before visibility. - Atomic activation of a complete candidate version and rollback. ```hint Separate validation from visibility Build the next version away from the serving path, then change which complete version is visible with one controlled transition. ``` ### Part 3 — Serve List and Detail Reads Design APIs and read models for product listing and product details. Address stable pagination, filtering or sorting fields if required, cache behavior, and the consistency expected immediately after a snapshot or override is published. #### What This Part Should Cover - Retailer-scoped list and stable-ID detail APIs. - Version-bound continuation tokens and deterministic ordering. - A consistent composition strategy for snapshot fields and overrides. ```hint Version the read path A continuation token tied to a catalog version prevents page two from being computed against a different snapshot than page one. ``` ### Part 4 — Operate, Recover, and Audit Handle duplicate uploads, validation failure, concurrent overrides, rollback, stale caches, and a retailer sending an unexpectedly small snapshot. Explain how operators can trace every visible attribute to its imported value or administrative override. #### What This Part Should Cover - Optimistic concurrency or another lost-update safeguard. - Versioned cache invalidation and state reconciliation. - Attribute-level provenance, metrics, alerts, and repair history. ```hint Treat a sharp count drop as suspicious A complete snapshot that suddenly contains far fewer products may be technically valid but operationally unsafe to publish automatically. ``` ### What a Strong Answer Covers - Immutable or versioned snapshots with an atomic active-version pointer. - Explicit deletion and override-precedence rules. - Read APIs that remain stable across pagination and publication. - Idempotent ingestion, validation gates, rollback, cache invalidation, and audit history. - Tenant isolation so one retailer's import or failure does not corrupt another catalog. ### Follow-up Questions 1. How would you publish a very large snapshot without one huge database transaction? 2. What happens when an administrator overrides a field that disappears from the next retailer snapshot? 3. How would you compare two catalog versions before promotion? 4. Which freshness and ingestion metrics would you alert on?