A company is building a generative AI (GenAI) application that uses Amazon Bedrock APIs to process complex customer inquiries. During peak usage periods, the application experiences intermittent API…

Question

Options

• AImplement a standard retry strategy that uses a 1-second fixed delay between attempts and a 3-
• BImplement an adaptive retry strategy that uses exponential backoff with jitter and a circuit breaker
• CUse the AWS SDK to configure a retry strategy in standard mode. Wrap Amazon Bedrock API
• DSet Amazon Bedrock client request timeouts to 30 seconds. Implement client-side load shedding.

• A
  7% (2)
• B
  48% (14)
• C
  31% (9)
• D
  14% (4)

Explanation

Option B best meets all requirements because it combines AWS-recommended resiliency patterns for transient failures with streaming-aware handling and adaptive protection against cascading retries during peak load. When timeouts and throttling occur, naive retries can amplify traffic and worsen outages. Exponential backoff with jitter is the standard AWS best practice because it spreads retry attempts over time, reduces synchronized retry storms, and lowers the probability of repeatedly colliding with service limits. The requirement also states the strategy must "adapt to changing service availability" and "prevent overwhelming Amazon Bedrock." A circuit breaker pattern directly addresses this by temporarily stopping or reducing retries when failure rates exceed a threshold, allowing the system to degrade gracefully instead of continually hammering the service. This is a key mechanism to prevent cascading failures during throttling events. Because the application uses response streaming and experiences broken chunks, the retry strategy must be streaming-aware. A streaming response handler that detects chunk delivery timeouts and buffers already received chunks prevents the user from losing progress when a connection drops. Resuming from the last successfully received chunk minimizes redundant generation and reduces additional load on the model compared with restarting the entire stream. This supports better user experience and better service efficiency during intermittent failures. Token-aware request handling is supported in this architecture because the application can apply token budgeting before invoking the model (for example, trimming or summarizing excessive context) while still preserving streaming output behavior. Option B provides the correct backbone for this by focusing on adaptive control and robust streaming recovery.

No community discussion yet for this question.