Design a service that lets sellers upload images for products and makes approved images available to product-detail clients. Walk through the upload path, image processing, metadata, serving path, failure handling, and access controls. ### Constraints & Assumptions - Original files can be large and should not pass through an application server unnecessarily. - A product may have several images and sellers may replace or reorder them. - Processing may generate several sizes and may reject an invalid or unsafe file. - Do not assume exact traffic or latency targets; identify the measurements needed to size the design. ### Clarifying Questions to Ask - Which formats, maximum file sizes, and image counts per product are supported? - Must an image be moderated before it is visible, and can sellers preview pending images? - What consistency is required when an image is replaced or reordered? ```hint Separate bytes from metadata Treat the large binary object and the product-facing state transition as related but independently durable workflows. ``` ### What a Strong Answer Covers - A direct-to-object-storage upload flow with short-lived authorization and content limits. - A durable metadata state machine that separates uploaded, processing, approved, rejected, and deleted states. - Asynchronous validation, decoding, resizing, moderation, retries, and idempotency. - CDN delivery with immutable object versions and safe cache invalidation. - Seller authorization, tenant isolation, malware and decompression-bomb defenses, observability, and cleanup of abandoned uploads. ### Follow-up Questions - How would you preserve the old image until a replacement is fully processed? - How would you diagnose a report that the product page shows a stale image? - How would the design handle a regional object-storage outage?