An HR management application named StaffSync records employee clock-in and clock-out events to an Amazon DynamoDB table. During the start of a morning shift, hundreds of employees clock in at the exact same minute. The application code makes direct write requests using a custom HTTP client without retry logic. This results in unhandled ProvisionedThroughputExceededException errors and application crashes, even though the table's total provisioned write capacity is not fully exhausted.
Which of the following is the most effective developer-centric solution to resolve these application crashes during brief write spikes?
- Configure the client application to retry failed writes using the AWS SDK's built-in retry mechanism with exponential backoff and jitter.Answer
- BIncrease the DynamoDB table's overall provisioned Write Capacity Units (WCUs) to handle the short-lived spikes.
- CPerform a DynamoDB Scan operation before each write to verify if the employee has already clocked in for the day.
- DConfigure a larger Amazon SQS visibility timeout on the DynamoDB table to queue the write requests automatically.
Answer
Configure the client application to retry failed writes using the AWS SDK's built-in retry mechanism with exponential backoff and jitter.
The correct option is to configure the client application to retry failed writes using the AWS SDK's built-in retry mechanism with exponential backoff and jitter. When DynamoDB throws a ProvisionedThroughputExceededException, it is often a transient error due to a brief spike in traffic. Implementing client-side retries with exponential backoff and jitter allows the client to pause, back off, and retry the request, which successfully handles the throttling event without requiring database schema changes or capacity increases.
Step-by-Step Solution
Key Concept
Handling ProvisionedThroughputExceededException with Client-Side Retry Policies