SAA-C03 Design Resilient Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Keep HTTP calls but add longer client timeouts so orders requests wait for slow downstream responses.

  Why it's wrong here

  Adding longer client timeouts does not reduce the orders service's dependency on slow downstream services; it only increases how long the orders service will wait. While waiting, the orders service occupies a worker thread and an outbound HTTP connection from its connection pool, both of which are finite resources. Under sustained slow or failed inventory/shipping responses, this can exhaust those pools, causing new order requests to be rejected or queued. It also means callers of the orders API still experience high latency during an outage, rather than receiving a fast success with the work decoupled.

• ✓

  Introduce Amazon SQS as a buffer between orders and downstream services, with consumers processing from the queue.

  Why this is correct

  SQS decouples the producer (orders service) from the consumers (inventory/shipping processors). The orders service can quickly enqueue work and return to the caller, even if a downstream service is slow or restarted. Messages remain in the queue until consumers can process them, preventing cascading latency/backpressure from propagating to the orders API.

• ✗

  Replace the downstream services with AWS Lambda functions that are invoked synchronously by the orders service.

  Why it's wrong here

  Synchronously invoking AWS Lambda from the orders service preserves the exact same request/response coupling as the original HTTP calls. The orders service must block until the Lambda returns, so any latency or throttling in the inventory or shipping function directly increases the order API's response time. Lambda concurrency limits and cold starts add additional variability and failure modes, and there is no buffer to absorb downstream outages or bursts. This approach would need custom retry logic and still cannot prevent cascading failures during high load.

• ✗

  Call the downstream services in parallel threads to reduce waiting time during peak load.

  Why it's wrong here

  Parallel calls may reduce response time briefly, but it does not eliminate the coupling to downstream availability/latency. If inventory is slow, parallelism still consumes resources and can degrade overall responsiveness under sustained load or failures.

Go deeper

Related to this question