A cliff-rail timetable site needs each clerk to see their own writes while the Cosmos account stays on the service default. Which consistency level should the developer name?
Select an answer to reveal the explanation.
Short Explanation
Clerks need read-your-writes after a save—not a global fortress. Session is the Cosmos default for that feel inside one session, usually via a session token. Do not jump straight to Strong for every screen.
Full Explanation
A cliff-rail timetable site where each clerk must see their own writes while the Cosmos account stays on the service default should use Session consistency. Session is the usual account default and delivers read-your-writes and write-follows-reads inside a client session when the SDK reuses the session token. That fits interactive clerk screens without forcing every request onto the strongest, most expensive guarantee.
Forcing Strong for every interactive clerk session ignores cost, latency, and availability trade-offs and is unnecessary when the requirement is personal write visibility rather than global linearizability. Eventual is not the mandatory account default for user-facing apps and does not guarantee that a clerk will immediately read back what they just saved. Bounded staleness with K=0 is not a shorthand for Strong; bounded staleness is defined by maximum lag in versions or time, and K=0 is not how you obtain worldwide linearizable reads.
Exam caveat: Session guarantees apply within a session. A brand-new client without the session token does not automatically inherit another clerk’s read-your-writes view.
Operational check: capture and reuse the session token (or rely on the SDK’s session cache for the same client instance) after a clerk save, then read the same item and confirm the updated timetable fields appear before considering a stronger account-wide change.