A county must summarize a large backlog of ordinance PDFs without blocking interactive clerk applications on long foundation-model calls. Which FM API integration pattern best fits?
Select an answer to reveal the explanation.
Short Explanation
A warehouse of ordinance PDFs is a freight train, not a counter question. Park the freight on an SQS siding for async FM processing so the clerk’s interactive apps keep moving.
Full Explanation
Asynchronous foundation-model processing with queues such as Amazon SQS decouples a county’s bulk ordinance-PDF summarization from interactive clerk applications. Workers pull jobs, call Bedrock, and store results without holding clerk UI threads open for long generations. That FM API integration pattern fits warehouse-scale document backlogs: freight stays on a queue siding while counter apps keep responding. Running each PDF summarization synchronously inside the clerk UI request thread until completion fails responsiveness—the UI blocks on long FM calls and timeouts cascade into clerk frustration. Pasting ordinances into a public consumer chatbot overnight and saving screenshots fails confidentiality, automation, and evidence quality for official corpora. Increasing API Gateway timeouts to one hour and keeping all work synchronous fails architecture: longer timeouts do not make bulk FM work appropriate on interactive request paths and amplify failure blast radius. Exam caveat: async jobs need progress tracking, dead-letter handling, and idempotency for redelivered PDFs. Apply the same Guardrails and retention rules as interactive paths. Size worker concurrency to Bedrock quotas so the backlog drain does not starve higher-priority interactive FM traffic. Operational check: Enqueue summarization jobs on ingest; process with workers that call Bedrock; persist summaries to the approved store; alarm on DLQ depth and age; and verify interactive clerk apps never await bulk job completion on their request threads.