Design a Product Catalog Service for Promotion Write Surges and Image Integrity

In a product architecture round, design a catalog system. Businesses publish catalogs of products, each with a title, description, structured attributes, a price, availability and a set of images, and those products are shown to a consumer audience the size of a large social network on product pages, shop pages and feeds. The interviewer expects you to move from requirements to core entities and APIs, then to a high-level design, and then into deep dives. Two deep dives are central: marketing events that suddenly generate a massive volume of writes, and keeping the images that arrive with uploaded catalogs intact and attached to the right products. No traffic or storage figures are given, so state your own estimates as assumptions. Because this is a product-focused round, weight the discussion toward APIs, the data model and product behavior rather than storage-engine internals. ### Clarifying Questions - Who writes to the catalog: small sellers editing items in an app, large merchants pushing bulk files or feeds, or both? - What does a marketing event look like: a planned sale where many prices change at a set time, last-minute bulk edits, rapid availability changes, or all of these? - How fresh must price and availability be for shoppers, and does a purchase re-check the price against the source of truth? - What does image integrity mean for the product: uploads that are not corrupted or truncated, images attached to the right product, images that meet content policy, or all of these? - Does the catalog serve search itself, or feed a separate search system? ### Part 1 — Requirements, entities and APIs Define functional and non-functional requirements for both merchants and shoppers, the core entities, and the main APIs, including how bulk uploads and image uploads work. ```hint Two audiences, two profiles Merchants and shoppers differ by orders of magnitude in volume and in how fresh their view must be; let that split drive the requirements. ``` #### What This Part Should Cover - Functional requirements for the merchant side and the shopper side - Non-functional targets that reflect the read and write asymmetry - Entities that separate fast-changing fields and reference images - APIs for single edits, asynchronous bulk imports and image uploads ### Part 2 — High-level design Lay out the write path for a single edit and for a bulk upload, and the read path for a product page. Explain where data lives, how it is partitioned, and how changes reach caches and downstream consumers such as search and feeds. ```hint Accept now, apply later Decide what a merchant must hear back immediately and what can safely finish in the background. ``` #### What This Part Should Cover - Storage choice and partitioning key - Synchronous versus asynchronous write handling - Read caching and denormalized views - Change propagation to downstream systems ### Part 3 — Marketing-event write surges A major sales event causes a sudden flood of catalog writes. Explain how the system absorbs it without hurting shopper reads, interactive edits from other merchants, or data correctness. ```hint Know the shape of the spike Ask which parts of the surge are known in advance, and what that lets you do before the event begins. ``` #### What This Part Should Cover - Changing the shape of the writes, not only adding capacity - Prioritization and per-merchant fairness - Hot partitions and cache invalidation under load - Backpressure, and what merchants see while it happens ### Part 4 — Integrity of uploaded catalog images Explain how you guarantee that every image a shopper sees is complete, safe and attached to the right product, from the merchant's upload to the shopper's screen. ```hint Follow one image Trace a single image end to end and list each point where it could be lost, corrupted, swapped or unsafe. ``` #### What This Part Should Cover - Upload verification and handling of partial or failed uploads - Validation, processing and policy checks before an image goes live - Binding images to product versions so pages never show broken or mismatched images - Long-term storage, serving and cleanup ### What a Strong Answer Covers - Requirements that drive the design, with estimates stated as assumptions - A data model that separates descriptive data, offers, promotions and media - A design that isolates the write surge from reads and from other merchants - An end-to-end integrity story for images, not only a storage choice - Failure handling and observability: freshness lag, backlogs, broken-image rates - Explicit trade-offs, such as computing prices at read time versus materializing them ### Follow-up Questions - A merchant uploads a feed that sets every price to zero. How do you detect it and recover? - How would you serve the catalog from several regions while merchants write from anywhere? - How do you keep search results consistent with a price change that just went live? - Two merchants upload the same image. Should they share storage, and what are the risks?