An architect is designing an API integration where Claude processes large document analysis requests that take 45–90 seconds to complete. The client applications cannot maintain long HTTP connections reliably. Which delivery pattern should the architect implement?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — you want webhook-based delivery because it decouples request submission from result delivery. You submit the request, get an immediate acknowledgment, and receive results via callback when processing finishes. That keeps you from relying on a long-lived HTTP connection during the 45–90 second wait.
Full Explanation
The webhook-based delivery pattern is correct because it decouples request submission from result delivery entirely. The client fire-and-forgets the request, receives an immediate acknowledgment with a job ID, and the orchestration layer calls the provided callback URL with results when processing completes. This pattern is resilient to client connection instability and network interruptions during processing. The polling pattern is wrong because it wastes bandwidth and server resources across 45–90 second processing windows, requiring 18 or more poll cycles at 5-second intervals per request, and it adds latency equal to the poll interval after completion. The streaming server-sent events pattern is wrong because it requires the client to maintain an open connection for the full processing duration, which is precisely the reliability problem the architect is trying to solve. The increased HTTP client timeout option is wrong because extending client timeouts is a fragile workaround that fails on mobile networks, serverless functions with execution time limits, and environments where proxies impose their own timeout limits.