A city's vital-records print shop falls behind when peak online orders hit printers synchronously from the web tier. Which change best loosens coupling and absorbs the spike?
Select an answer to reveal the explanation.
Short Explanation
Think of the print shop like a take-a-number deli, not a phone that rings until someone picks up. Drop each order on an SQS queue so the web tier can finish the citizen's click while workers chew through spikes at their own pace. Synchronous sockets, bigger thread pools, and raw NFS shares still glue the web tier to printer speed.
Full Explanation
When a city’s vital-records print shop falls behind because peak online orders hit printers synchronously from the web tier, the change that loosens coupling and absorbs the spike is placing an Amazon SQS queue between the web tier and print workers so orders buffer asynchronously. The website accepts the order quickly; workers pull at printer-safe rates; spikes become queue depth instead of dropped HTTP requests. That is the municipal print-shop analog of a ticket take-a-number system.
Having the web tier call each printer over a long-lived TCP socket and block until ink confirms tightly couples web availability to device health. Increasing the web tier’s thread pool so more synchronous printer calls run in parallel multiplies load on already overwhelmed printers and still blocks request threads. Replacing printers with a single shared NFS mount that the web tier writes PDFs into directly may move files, but it does not provide competing consumers, visibility timeouts, or DLQ semantics for failed print attempts.
Exam caveat: SQS buffers work; it does not print. You still need workers, idempotent print jobs, and operational alerts on age-of-oldest-message when toner or devices fail.
Operational check: enqueue print jobs with record IDs; scale workers from queue depth; make print completion idempotent; configure a DLQ; and dashboard queue lag during birth-certificate rush periods.