A globally replicated municipal settings table holds feature flags for kiosk apps that can tolerate brief staleness. Which DynamoDB read consistency choice is appropriate by default?
Select an answer to reveal the explanation.
Short Explanation
Kiosk flags that can be a moment behind don’t need a strongly consistent hammer every poll. Eventual consistency is cheaper and faster when brief staleness is fine.
Full Explanation
Globally replicated municipal feature flags for kiosk apps that can tolerate brief staleness should default to eventually consistent DynamoDB reads. Eventual consistency lowers read cost and latency compared with always demanding strong consistency, and it matches kiosk UX where a flag flipping a few hundred milliseconds later is acceptable. Strong consistency is still available when a specific check cannot tolerate staleness, but it should be the exception driven by SLO, not the blanket default.
Always using strongly consistent reads in every Region for every flag check pays unnecessary latency and capacity cost when the stem already allows brief staleness. Forcing transactional reads on each kiosk poll adds TransactGetItems overhead unrelated to ordinary flag freshness needs. Replicating flags only through handwritten S3 copies abandons DynamoDB’s managed replication and read APIs for a brittle side channel.
Exam caveat: “eventually consistent” is the DynamoDB default for GetItem/Query/Scan; strongly consistent reads are same-Region only and cost more—multi-Region global tables have their own replication lag story separate from local strong reads. Operational check: measure p99 flag-read latency and RCU with eventual versus strong under kiosk poll load, and confirm product accepts the observed staleness window after a flag update in one Region.