Design a Product Photography Upload Service

# Design a Product Photography Upload Service Design a service for a commerce platform's product-photography workflow. A merchant ships an item to a studio, a photographer captures one or more photos, and the merchant can review the results and request a reshoot when dissatisfied. Cover the workflow from creating a shoot through upload, processing, review, acceptance, and reshoot. Define APIs for submission, upload authorization, status queries, review decisions, and cancellation. Explain how large files reach object storage, where metadata lives, and how users learn that processing or upload has completed. ### Constraints & Assumptions - Original images are large enough that routing bytes through the application tier is undesirable. - Upload authorization must be scoped to a specific shoot and object, expire, and prevent arbitrary storage writes. - Upload completion notifications can be duplicated, delayed, or delivered out of order. - A shoot may contain several attempts, but only an accepted attempt becomes the published asset set. - The appropriate notification mechanism depends on traffic and product latency needs; compare push, event-driven, and polling approaches rather than assuming one. ### Clarifying Questions to Ask - Who creates the shoot and maps it to a merchant and item? - Which image formats, sizes, transformations, and moderation checks are required? - Is near-real-time progress necessary, or is eventual status acceptable? - What are the retention and deletion rules for rejected attempts? - Can a merchant review while some files are still processing? ### What a Strong Answer Covers - A coherent state machine and idempotent transitions. - Secure direct-upload authorization plus authoritative metadata. - Reliable completion detection, processing, and user notification. - Failure recovery, observability, consistency, and cost-sensitive scaling choices. ### Follow-up Questions 1. How would you resume a multipart upload after a client disconnects? 2. How would you prevent a stale completion event from publishing a rejected attempt? 3. When would polling be preferable to a persistent push channel? 4. How would the design change for untrusted public uploaders?