A script every five minutes scans a DynamoDB table for unpaid invoices to email reminders, burning read capacity mostly on no-op scans. Which approach better fits an event-driven design?
Select an answer to reveal the explanation.
Short Explanation
Don't walk every parking meter on the block every five minutes looking for expired ones—react when a meter expires. Streams, events, or narrow queries beat a hammering full-table Scan for unpaid-invoice reminders. Bigger capacity or bigger boxes just make wasteful polling more expensive.
Full Explanation
A script that every five minutes scans a DynamoDB table for unpaid invoices to email reminders—burning read capacity mostly on no-op scans—should prefer event or stream-driven triggers (or targeted queries) instead of wasteful full-table polling. DynamoDB Streams on status changes, a sparse GSI of unpaid items, or scheduled queries against that index wake work when state actually changes. Capacity then tracks real transitions rather than repeatedly rereading paid rows. Municipal finance automation should spend read units on signal, not on ritual full-table tours.
Raising provisioned read capacity and keeping full-table scans treats the cost symptom while leaving the design flawed. Moving the same Scan onto a larger EC2 instance merely accelerates waste. Exporting the whole table to S3 Glacier Deep Archive before each reminder run adds latency and cost without creating an event-driven path.
Exam caveat: rare reconciliation scans can remain as audit controls; they should not be the primary five-minute reminder engine. Stream processors must be idempotent so duplicate “became unpaid” signals do not spam residents.
Operational check: capture unpaid/became-due transitions via streams or selective queries; drive reminders from those signals; compare consumed read capacity before and after; suppress duplicate emails with a sent-reminder marker; and keep an occasional audit scan off the hot path.