Clients submitting long-running records requests need a fast acknowledgment while work continues asynchronously. Which edge pattern best fits?
Select an answer to reveal the explanation.
Short Explanation
Take a ticket at the counter—API Gateway drops work on SQS and hands back a fast “we’ve got it,” while the shop works in the back. Making citizens wait hours on an open HTTP call is the opposite of loose coupling.
Full Explanation
Clients submitting long-running records requests should get a fast acknowledgment by integrating Amazon API Gateway with Amazon SQS: the edge accepts the request, enqueues work, and returns quickly while workers process asynchronously. That ticket-at-the-counter pattern keeps HTTP interactions short and municipal back-office processing loosely coupled from citizen wait time.
Having API Gateway synchronously wait for multi-hour batch jobs before returning any HTTP response fails by concept because gateway and client timeouts make multi-hour synchronous waits impractical and fragile. Blocking the client TCP connection open until operators finish manual processing fails for the same reason—long-held connections are not an async architecture. Returning HTTP 500 immediately for every request so clients learn to avoid the API fails as intentional denial rather than an acceptance pattern.
Exam caveat: Long-running work + fast client ack → API Gateway to SQS (or similar async offload), not synchronous multi-hour waits or deliberate 500s.
Operational check: Confirm the integration returns success on enqueue, workers consume SQS and update status stores citizens can poll, DLQs capture failures, and API Gateway timeouts are appropriate for the ack path only. If clients still sit on open connections for hours, the async edge pattern is not deployed.