App Needs Consistency Control? Change Cosmos DB Consistency Level

A customer changes a product’s price, then reads it again. Cosmos DB keeps several copies of the data, and those copies can receive updates at different times. The consistency level defines how fresh and ordered a read must be. Session lets a client session read its own writes; Eventual allows temporarily older values while the copies catch up.

Use cosmos-ctappeus from the account creation trip, in rg-cloudtrips-cosmos-test-eus. This exercise uses only the portal.

Change to Eventual

Open cosmos-ctappeus → Default consistency. Note the current setting, select Eventual, and choose Save. Wait for the update to finish, then reopen the page.

Check Eventual remains selected. With this setting, reads can return an older value; replicas converge when updates stop. This can suit a catalog display that tolerates a short delay.

Restore Session

On the same page, select Session → Save. Wait for completion and reopen the page.

Check Session remains selected. Cosmos SDKs track session tokens so subsequent reads in that session include its earlier writes. Other sessions can still see older values while replication catches up.

These screenshots verify the saved account setting. Observing a stale read depends on request timing and replication; this single-region portal exercise may show the newest value under either setting.

Choose a Consistency Level

Start with Session for most user-facing apps. Choose another level when you have a specific freshness or ordering requirement.

Level	What it guarantees	When to use it
Strong	Reads return the latest committed value.	Decisions require the latest saved state.
Bounded staleness	Reads may lag within a configured time or version limit.	Regional readers need a defined maximum delay.
Session	Within a client session, you see your own writes and reads stay consistent.	Shopping carts, profiles, interactive apps.
Consistent prefix	Updates appear in their write order, though they may arrive late.	Readers need an ordered sequence and tolerate delay.
Eventual	Copies converge when writes stop; freshness and ordering can vary meanwhile.	Approximate counters or displays that tolerate older values.

Tradeoff: Strong and Bounded staleness reads cost roughly twice the request units of equivalent Session reads. Strong also adds cross-region write latency and requires a single write region.

A session here is tracked by the database SDK through session tokens; your website’s login session is a separate concept.

Keep Session selected and retain the account for the next trip. This exercise creates no additional resources.