Design a Large Catalog Update Propagation System

Identified scale (SKUs, updates/sec, flash-sale peaks) and asked about consumer types and ordering/consistency needs
Clarified critical-latency fields (price/inventory) vs eventually-consistent ones (recommendations)
Explicitly scoped out catalog authoring/business logic to focus on propagation

Proposed a durable, ordered event log (e.g., Kafka) as the propagation backbone, partitioned by SKU
Designed distinct fan-out workers/consumer groups per downstream system (search, cache, partner feeds)
Included a source-of-truth catalog store separate from the event log, with versioning
Included a backfill/reconciliation mechanism for new or recovering consumers

Defined ingestion API with versioning/optimistic concurrency
Defined consumer-facing lag/backfill APIs
Schema includes per-SKU partition key for ordering and a checkpoint/offset store per consumer

Explained per-SKU ordering guarantee via partitioning and addressed hot-key/skew mitigation
Explained idempotency via monotonic versions to handle at-least-once delivery
Addressed high-frequency update coalescing for hot items (flash sales) to avoid write amplification
Discussed consumer lag monitoring, backpressure, and priority lanes for critical consumers
Articulated at least 3 clear trade-offs (e.g., ordering vs skew, at-least-once vs exactly-once)

Structured the discussion within time budget, prioritizing high-level design before deep dives
Proactively surfaced failure/recovery handling (DLQ, retries, reconciliation) without prompting
Delivered a concise, confident opening statement/summary tying the design together

Problem