# Design a Concurrent Image Processing Service Design an image-processing service in two stages. First, support one processor safely. Then scale to multiple processors without losing, duplicating, or concurrently corrupting jobs. Define APIs to submit a job, query status, and request cancellation. A job references an input image and an ordered list of transformations. Discuss validation, queueing, producer-consumer coordination, thread safety, idempotency, retries, result storage, and what cancellation can guarantee once processing has begun. ### Constraints & Assumptions - Image bytes live in object storage; API requests carry references rather than large payloads. - A transformation can fail permanently or transiently. - Status reads may race with worker completion or cancellation. - Duplicate submit and delivery attempts are possible. - The service must never publish a partial output as a successful result. ### Clarifying Questions to Ask - Which transformations and image limits are supported? - Must results preserve the exact submitted transform order? - Is cancellation best-effort or guaranteed before publication? - Can a completed result be reused for an identical request? - What latency, throughput, retention, and isolation requirements apply? ### What a Strong Answer Covers - A precise state machine and atomic ownership protocol. - Safe single-worker code that evolves naturally to many workers. - Idempotent output publication, bounded retries, and cancellation semantics. - Backpressure, observability, security, and scaling trade-offs. ### Follow-up Questions 1. How would you prevent two workers from executing the same leased job? 2. How would you handle a worker that completes after its lease expires? 3. When is caching transformed results safe? 4. How would GPU-based transforms change scheduling?