After a cashier posts a fee, the next read of the resident balance on another path sometimes shows the old amount when using eventually consistent reads. Staff need the latest balance immediately. What should the developer select?

After a cashier posts a fee, the next read of the resident balance on another path sometimes shows the stale amount under eventually consistent reads. Staff who need the latest balance immediately should use strongly consistent reads for that lookup, accepting the consistency tradeoffs. Strong reads return the latest successful write for that item on the standard consistency model DynamoDB provides, which matches counter workflows where handing a citizen an outdated balance creates disputes and rework.

Caching balances only in the cashier browser and never re-reading DynamoDB after a write invites divergence across kiosks. Using a full table Scan with eventual consistency and displaying whichever item returns first is neither keyed access nor strong consistency. Stopping fee payments so staleness cannot occur “solves” consistency by breaking the business.

Exam caveat: strong consistency is not available on all read patterns (for example some GSI reads are eventually consistent only)—design keys so the balance item can be GetItem/Query strongly when required. Strong reads can cost more and have slightly different latency; use them where freshness is mandatory, not universally by dogma.

Operational check: switch the post-payment balance lookup to ConsistentRead=true (or equivalent); test read-after-write at the cashier; keep eventually consistent reads for non-critical dashboards; and document which paths require strong consistency in the fee API guide.