A city permit API spikes when storm season opens, overwhelming workers that process applications synchronously. How should the architect loosely couple intake from processing so each tier can scale independently?
Select an answer to reveal the explanation.
Short Explanation
When the storm permit line explodes, do not make the clerk and the back office share one heartbeat. Drop requests on SQS so the API keeps accepting while workers chew through the pile at their own pace. One fat box still sync-calling is a traffic jam with a bigger engine.
Full Explanation
Storm-season spikes on a city permit API overwhelm synchronous workers because intake and processing share one request timeline. Placing an Amazon SQS queue between the API and workers loosely couples the tiers: the API enqueues permit applications quickly and returns, while workers scale independently to drain the queue. That buffering absorbs burst traffic, improves resilience to worker slowdowns, and is the classic AWS pattern for decoupling producers and consumers in civic workloads.
Running all processing inside the API request thread with no buffering couples latency and failure domains so timeouts cascade to citizens. Requiring in-person retries at city hall during spikes is not an architecture and fails digital service goals. Vertically scaling a single worker host while keeping a tight synchronous call path still leaves a scaling bottleneck and a single host risk; bigger boxes do not create asynchronous decoupling.
Exam caveat: SQS is the simple queue for load leveling; do not pick SNS when the need is work buffering to competing consumers, and do not pick Step Functions unless orchestration state is required. Operational check: put the API on enqueue-only path, autoscale workers on ApproximateNumberOfMessagesVisible, configure DLQs for poison messages, and load-test storm-season arrival rates without growing API timeouts.