A consistency model defines when changes become visible to other users and how current or ordered their reads are. Cosmos DB offers five levels, trading data freshness against latency, throughput, and availability. section 11.4.1
Choose the level that matches the application’s tolerance for stale or differently ordered data:
- Strong returns the newest write to every client, but increases latency and reduces throughput; it suits critical inventory updates. section 11.4.1
- Bounded staleness limits how far reads trail writes by a specified time interval or version count, balancing freshness with throughput and availability. section 11.4.1
- Session preserves consistency within one client session and is useful for user-specific operations. section 11.4.1
- Consistent prefix ensures that reads observe writes in order, without necessarily seeing the latest write. section 11.4.1
- Eventual maximizes performance and availability when temporary staleness is acceptable, such as for noncritical applications. section 11.4.1
Setting a default level
An Azure CLI account-creation command sets the default consistency level to Session, giving the application a balance between read consistency and throughput. section 11.1
Table 11.1 Comparing the consistency models in Cosmos DB
| Consistency model |
Description |
Behavior |
Tradeoffs |
Uses |
| Strong |
Guarantees that reads always return the most recent write |
Ensures that all clients see the same data concurrently |
Highest latency and lowest throughput due to the need for synchronization across regions |
Critical operations such as updating inventory levels to ensure customers don’t purchase out-of-stock items |
| Bounded staleness |
Reads lag behind writes by a predetermined time interval or a number of versions |
Guarantees that reads aren’t more than the specified interval or versions behind the most recent write |
Balances between strong consistency and higher throughput/availability |
Order processing, ensuring order confirmations are consistent within a defined time window |
| Session |
Guarantees consistency within a single client session |
Ensures that within a session, reads never see out-of-order writes, and the most recent write is always visible |
Offers a good balance of consistency and performance for session-scoped operations |
User-specific operations, such as updating a shopping cart |
| Consistent prefix |
Ensures that reads never see out-of-order writes |
Ensures writes are seen in the order they were committed, though not necessarily the most recent writes |
Higher throughput and lower latency than strong consistency, but less strict than session or bounded staleness |
Maintaining ordered logs or events, such as customer interactions and activity logs |
| Eventual |
Guarantees that all writes will eventually be visible, but there are no ordering guarantees |
Ensures data is replicated across regions, but a lag may occur before all replicas reflect the latest write |
Offers the best performance and availability but at the cost of potential data staleness and out-of-order reads |
Noncritical analytics, such as generating product recommendations |
Compare each consistency model’s read behavior, trade-offs, and suitable application scenarios. section 11.4.1
