A seasonal city tax portal sees quiet winters and sharp April filing spikes. Which DynamoDB capacity approach best matches that traffic shape?
Select an answer to reveal the explanation.
Short Explanation
April tax season is a flash crowd, not a steady drip. On-demand capacity rides the spike without you guessing January-sized provisioned numbers that throttle in spring.
Full Explanation
Seasonal city tax portals are quiet most of the year and spike hard around April filing deadlines. On-demand capacity mode lets DynamoDB absorb those request spikes without locking in provisioned read/write units sized for the peak all year, which is the capacity approach that matches bursty civic traffic when peaks are sharp and infrequent relative to idle months.
Provisioned mode locked to January average traffic with no autoscaling will throttle when filings surge, producing citizen-facing errors at the worst time. Disabling retries and treating ProvisionedThroughputExceeded as expected UX normalizes failure instead of sizing for elasticity. Replacing DynamoDB with instance-store on a single EC2 host for April destroys durability, shared access, and managed scaling—scratch disk is not a system of record for tax filings.
Exam caveat: on-demand still has account-level scaling and throttling behaviors under extreme sudden jumps; warm the table with gradual traffic or request limit increases when April spikes are known in advance. Operational check: review ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits and ThrottledRequests around a load test that simulates April concurrency, confirming on-demand absorbs the surge without application-level errors.