A city records portal accepts citizen uploads on an API tier and must virus-scan files with a separate worker fleet. How should the architect enable each tier to scale independently under load?
Select an answer to reveal the explanation.
Short Explanation
Don’t chain the front desk to the back-room scanner with the same rope. Park upload messages on SQS so the API and scan workers scale on their own clocks. One process, instance-store queues, or a global mutex turns spikes into a traffic jam.
Full Explanation
Independent scale for an upload API and a virus-scan worker fleet requires loose coupling. Amazon SQS between the city records portal API and the scanners lets the API acknowledge citizen uploads quickly while workers consume scan jobs at their own rate, so each tier scales on its own metrics during load spikes. That queue-based decoupling is a classic Task 3.2 high-performing compute pattern for civic upload pipelines with heavier asynchronous work behind the front door. Running virus scanning inside the same API process so one scale policy covers both fails because slow scans block or enlarge the API tier, coupling two different resource profiles under one scaling decision. Storing pending scans only in instance store on the API hosts fails conceptually: ephemeral local disks are not a durable shared queue, disappear with the instance, and cannot safely coordinate a separate worker fleet. Using a single global mutex in DynamoDB that allows one upload and one scan at a time fails because extreme serialization destroys throughput and prevents elastic parallel processing of citizen uploads. Exam caveat: SQS enables independent scale but you still handle poison messages, visibility timeouts for long scans, and idempotent scan results so retries do not confuse records retention. Operational check: API enqueues object references after durable store, workers scale on ApproximateNumberOfMessages, verify failed scans land in a DLQ, and load-test upload spikes without API latency collapsing into scan duration.