Citizens see intermittent ProvisionedThroughputExceeded during enrollment peaks. Besides blind retries, what should developers address?
Select an answer to reveal the explanation.
Short Explanation
Retries help a blip; they don’t fix a hot partition or an undersized table. Check keys, capacity mode, and caching so enrollment peaks stop lighting the throttle lamp.
Full Explanation
Intermittent ProvisionedThroughputExceeded during citizen enrollment peaks is rarely fixed by retries alone. Developers should review partition-key cardinality for hot partitions, adjust capacity mode or autoscaling targets, and add caching where reads dominate so the table absorbs peaks instead of merely retrying into the same throttle. Retries with exponential backoff remain useful for brief spikes, but they are not a substitute for capacity and key design when enrollment traffic repeatedly concentrates on the same partitions.
Deleting the table during peaks causes an outage and destroys enrollment state. “Eventually consistent Writes” is not a DynamoDB feature that bypasses throughput limits—writes consume write capacity regardless of read-consistency concepts borrowed from GetItem. Disabling CloudWatch metrics hides throttling instead of fixing it and removes the signals needed to tune capacity or detect hot keys.
Exam caveat: adaptive capacity helps uneven access, but a single hot partition key (for example one shared enrollment status value) can still throttle; on-demand mode may fit spiky enrollment better than undersized provisioned capacity. Operational check: graph ThrottledRequests and per-partition metrics during a peak drill, identify hot keys, and validate that capacity or key redesign plus cache hits eliminate citizen-facing throughput errors.