PDF generation for permit packets must not block the citizen API. How should the architect decouple and scale the workers?
Select an answer to reveal the explanation.
Short Explanation
Park the heavy PDF press on a side street: the API drops a ticket on SQS and workers clock in when the queue grows. Cranking the API box bigger still ties citizens to the printing press.
Full Explanation
PDF generation for permit packets should be decoupled from the citizen API by enqueueing jobs on Amazon SQS and scaling PDF workers on queue depth independently of the API tier. The API returns quickly after accepting the request; workers render packets asynchronously and scale out when the queue deepens during rush periods. That pattern keeps the interactive municipal API responsive while heavy rendering scales on its own axis.
Running PDF rendering inside the API request thread and only increasing API instance size fails by concept because it couples slow work to the request path and uses vertical scaling instead of decoupling. Generating PDFs only on the user’s phone with no server workers fails when the city must produce official permit packets server-side with controlled templates and auditability. Storing pending PDF jobs only in browser localStorage until an administrator prints them fails because client localStorage is not a durable, scalable work queue for municipal processing.
Exam caveat: Long-running or heavy work off the request path → SQS (or similar) + independently scaled workers. In-request rendering, phone-only generation, and browser localStorage are distractors for server-side async jobs.
Operational check: Measure API latency with PDFs offloaded, watch SQS depth drive worker Auto Scaling or Lambda concurrency, confirm DLQ captures failed renders, and ensure completed PDFs land in durable storage (typically S3). If API threads still block on PDF engines, decoupling is incomplete.