A fjord-ferry cargo board only displays a running “crates scanned” total in Cosmos DB. A slightly outdated number is acceptable and ordering across updates does not matter. Which consistency level fits?
Select an answer to reveal the explanation.
Short Explanation
A cargo tally that can be a little late is the classic “good enough” board. Eventual is the weakest Cosmos level when order does not matter. Do not haul Queue Storage into a consistency-level answer.
Full Explanation
A fjord-ferry cargo board that only displays a running “crates scanned” total and can accept a slightly outdated number with no need for ordered updates fits Eventual consistency. Eventual is the weakest of the five official Cosmos levels: reads may lag and ordering across updates is not guaranteed. That is appropriate for a low-stakes tally where freshness is nice-to-have rather than mandatory.
Strong would linearize every counter increment worldwide, adding latency and RU cost the board does not require. Bounded staleness with K forced to zero is not a legitimate way to express “Eventual but somehow Strong,” and inventing K=0 as a counter rule confuses bounded staleness with Strong. Azure Queue Storage peek-lock is a Domain 5 messaging pattern; it is not a Cosmos consistency level and does not configure how Cosmos replicas serve the crates-scanned document.
Exam caveat: Eventual can reorder or delay updates; if the cargo board later needs monotonic counters or read-your-writes for the clerk who just scanned a crate, promote that path to Session or stronger rather than leaving the whole account on Eventual by habit.
Operational check: set the display query to Eventual (account default or per-request override), sample RU charge versus Session/Strong for the same point read, and confirm the UI tolerates brief lag without treating the total as a financial ledger.