## Design a Read- and Write-Heavy Product Catalog Service Design a service in which merchants create and update product listings while users browse and view those products. The deep dive is the database and data path under both heavy write traffic and heavy read traffic. Keep ordering, payment, and warehouse inventory outside this exercise. A product listing has a stable product ID, merchant ID, title, description, price, status, version, and timestamps. Users can fetch one visible product and page through visible products; merchants can create, update, publish, and withdraw their own listings. ### Constraints & Assumptions - Do not assume request rates, catalog size, or a fixed freshness target; identify the measurements and product requirements that drive those choices. - Merchant writes for one product must be ordered and must not silently overwrite a concurrent edit. - User pagination must not duplicate or skip items merely because another listing changes between page requests. - Withdrawn products must stop appearing according to an explicit consistency contract. - Search ranking and free-text indexing may be delegated to a derived index, but the authoritative listing state must remain clear. ### Part 1 — Define APIs and the Authoritative Model Specify the user and merchant APIs, authorization checks, product lifecycle, database keys, and indexes. Include idempotent creation and conditional updates. #### What This Part Should Cover - Stable product identity and merchant ownership. - Draft, visible, and withdrawn lifecycle states. - Version-based write preconditions and a clear conflict response. - Read-by-ID and deterministic cursor-pagination access paths. ```hint Design from access paths List the exact keys and sort orders each read and write needs before choosing indexes or partitions. ``` ### Part 2 — Sustain High Write Volume Explain the write path from API validation through durable storage and downstream indexing. Address hot merchants, concurrent edits, retries, and propagation to read-oriented views. #### What This Part Should Cover - A partition key that spreads independent products without losing per-product ordering. - Transactions or compare-and-swap updates for listing state and version. - Idempotency for ambiguous create or update retries. - A durable change stream or outbox for cache and search-index updates. ```hint Commit once, project afterward Make one store authoritative, then derive read views from a durable record of committed changes. ``` ### Part 3 — Serve High Read Volume and Control Staleness Design the read path for product detail and catalog pages. Discuss replicas, caching, pagination, invalidation, hot products, failures, and observability. #### What This Part Should Cover - Cache keys that include or validate listing versions. - A stated read-after-write and withdrawal-visibility contract. - Stable cursor pagination rather than mutable numeric offsets. - Metrics for write conflicts, replication lag, cache behavior, projection lag, and stale reads. ```hint Put freshness in the contract A cache strategy cannot be judged until the design states how long an old listing may remain visible after a merchant update or withdrawal. ``` ### What a Strong Answer Covers - Connects API behavior to concrete database keys, indexes, and consistency rules. - Separates the authoritative write model from caches and search projections. - Handles concurrent writes, retry ambiguity, and pagination under mutation. - Explains scaling choices from measured load and skew instead of invented capacity numbers. ### Follow-up Questions 1. How would a merchant bulk import millions of listings without overwhelming online writes? 2. What changes if a product may be edited collaboratively by several merchant users? 3. How would you prove that a withdrawn product has disappeared from every public read path? 4. When should catalog browsing use a search index rather than the primary database?