A cashier kiosk must show the tax-due balance before printing a receipt; waiting a minute for eventual consistency is unacceptable for that click. Which interaction style should the balance lookup use?
Select an answer to reveal the explanation.
Short Explanation
When the drawer won't open until the number is right, you don't leave a sticky note for later—you ask and wait. That click needs a synchronous, authoritative answer. SNS fire-and-forget, post-print SQS polling, and overnight S3 reconciliation are fine for background work, not for the receipt moment.
Full Explanation
A cashier kiosk that must show the tax-due balance before printing a receipt cannot wait a minute for eventual consistency—those clicks need a synchronous request/response call that returns an authoritative balance before printing. The UI blocks briefly on a fast read path, prints with confidence, and avoids handing citizens receipts that disagree with the ledger. Synchronous style matches human-facing, decision-critical reads at the counter.
Fire-and-forget to SNS and printing whatever cached balance is on the kiosk risks stale amounts and citizen disputes. Enqueueing a balance request on SQS and polling after the receipt prints inverts the required order. Writing payment to S3 and relying on overnight reconciliation is far too slow for a cashiering moment of truth.
Exam caveat: synchronous does not mean “no queue anywhere in the enterprise”—async still fits receipts archival or analytics. For the balance lookup itself, choose strongly consistent reads or a system of record path that meets the freshness SLA.
Operational check: implement a low-latency balance API with appropriate consistency; time-box the kiosk call; refuse to print if balance lookup fails; and reconcile async side effects after the authoritative post.