A partial outage plus aggressive client retries turns into DynamoDB throttling across the fleet. What contributing cause should developers address?
Select an answer to reveal the explanation.
Short Explanation
Hammering retries during a blip can turn a limp into a DynamoDB stampede. Back off with jitter so the SDK is not the amplifier making throttling worse.
Full Explanation
A partial outage plus aggressive client retries that turns into DynamoDB throttling across the fleet points to retry amplification—retry storms. Clients without backoff and jitter hammer the same partitions while the system is already degraded, deepening throttling and lengthening recovery for municipal apps. Developers should tune exponential backoff, jitter, and retry limits so retries help individuals without stampeding the shared table.
Disabling exponential backoff forever so every client retries at full blast worsens storms and is the opposite of the fix.
Deleting CloudWatch metrics so throttles cannot be observed removes the signal needed to manage the incident.
Switching all reads to Scan with ConsistentRead increases load dramatically and is not an anti-throttle pattern.
Exam caveat: Retry storms are a classic distributed-systems failure mode tested via DynamoDB throttling scenarios.
Operational check: Add jittered exponential backoff in SDKs/clients, cap retries, shed load with queues where appropriate, watch ThrottledRequests fall, and retest under a controlled failure injection in a non-production civic environment. Keep the civic/municipal context in mind: citywide mobile clients can amplify a small outage into a DynamoDB meltdown within minutes.