CosmosDB — Session Consistency
Explore different scenario with one of mostly widely used consistency model
Azure Cosmos DB being globally distributed NoSQL database and at its core need to replicate the data across regions for high availability, low latency or both. Azure Cosmos DB offers five well-defined levels. From strongest to weakest, stronger the consistency better the consistency and weaker the consistency better the availability.
Following snap for reference where application teams would choose one of them based on their application requirements and tradeoff between consistency and availability.
In this blog, we would be focusing on the Session consistency which is the default consistency model and would first understand what session consistency is, how it works and different scenarios on how applications would behave when configured with session consistency.
What is Session consistency
Reads and writes are tagged with session tokens, the session tokens are scoped to the cosmos client through which the read and write request are performed. This is the best consistency model that would provide consistent reads if the reads were performed through the same client and with lower latency.
Lifecycle of Session Tokens
Session tokens are basically the current state of the individual document based on the update/create operations performed across regions on the respective document and they are scoped to physical partition.
Each physical partition has its own series of session tokens that are generated based on the operation performed on the logical partitions residing on them. For e.g.
- Document with key “A” on physical partition “P1” once added will be assigned session token “1” and document with key “B” on “P1” will be assigned session token “2”
- Document with key “C” on physical partition “P2” would be assigned session token “1”
Session Token is used as a minimum version barrier but not as a specific (possibly historical) version of the data to be retrieved
from the database.
Session Tokens format
The format of the session token would vary based on the number of the read/write regions and would typical be as below,
- Single write region <PartitionID>:<WriteRegion-Version-Id>#<LSN>
- Multi write region <PartitionID>:<HubRegion-Version-Id>#<LSN>#<Region#1>=<Region#1-VersionId>
Quorum Writes
All the consistency level except “strong” follow the local majority where the data is committed to three replicas in a four-replica set. “Strong” consistency uses Global majority where the changes need to be committed in every region. This can be little expensive in terms of performance and overall latency, but benefits are consistent data on every read operation.
Quorum Reads
Reads for the Session consistency would be done from single replica and the same applies for Eventual and Consistency Prefix. For strong and bounded staleness, reads are done against two replicas in a four-replica set (local minority quorum) to provide consistency guarantees which makes them 2x expensive.
Scenarios
Until now we have covered the basic understanding about the session tokens and how they would typically work on the Cosmos backend. From an application standpoint, developers would come across different scenarios and would be curious to understand how the application would behave when used with session consistency. We would be capturing here some common scenarios.
Scenario #1 — Read-your-own writes
With Read-Your-Writes consistency, once an item has been updated, the subsequent reads by the same client will return the updated value.
To achieve guaranteed Read-Your-Writes consistency,
- Have some mechanism in place to route the read request to the same client that performed the write request.
- If routing the request to the same client is not possible then make sure the read request stays in the same region that performed the write request. This would be simpler for Cosmos account configured with multi-write region. There is still possibility of stale updates in case of high throughput scenario.
Scenario #2 — Read across regions using session tokens
Session tokens can be passed when performing the Read operation to fetch the latest data which would be needed when,
- Reading from different region that performed the write operation
- Reading from different client/SDK that performed the write operation
PROS
- Fetch latest and updated data associated with the respective session token
- SDK would take care of getting the latest data across regions for the respective session token
CONS
- Adds up few milli-seconds latency on top of the overall end-to-end latency to fulfil the request
- Application teams need to have good strategy for maintaining the session tokens
Scenario #3— Write request with/without session tokens
Session tokens can also be used while performing the write operations which has its own pros and cons.
Scenario #1
- Write operation would session token would make the overall process faster but could result into conflicting updates.
- Suitable for workloads that do not have same documents being updated from across regions and preferably on single write region.
Scenario #2
- Write operation with session tokens would add up some latency and would make sure the data integrity across the session.
- Ideal for workloads that are multi-write region enabled and cannot tolerate writing/updating on top of stale data.
Summary
- Session consistency is the default consistency model where application teams can choose between consistent data versus latency. Use session tokens if your need is for up-to-date data with some added latency.
- Read/write performed using session consistency are economical in terms of cost and performance since the data would be read from single replica compared to bounded staleness and strong consistency.
- Every write operation would result in a new session token getting generated. The session tokens are scoped to physical partitions. For e.g.,
- If 2 unique documents are created on the same physical partitions, the session token versions would be incremented one after another as they share the same physical partition (e.g., 1:321, 1:322)
- If both the documents are created on two different physical partitions, both the session tokens would have different versions as per the physical partitions (e.g., 1:323, 2:5342) - In multi-region application deployment with the cosmos accounts being either single-write or multi-region, there would be a need to maintain sessions across the application instances. There are no recommendations for maintaining session tokens, but the teams can use the browser cookies or caching solution to maintain the session tokens.
- The replication sync between the regions has no guaranteed SLAs, ideally it should happen within milli-seconds but there can be scenarios where it would be delayed and would result in stale data.
- In multi-region application deployment, the best practice would be to route the write/read request for specific partition key to the same region. This would mostly ensure that you would see up-to-date data.
- Managing session tokens is only applicable for the NoSQL API, for the other API like Cosmos Mongo, Cosmos Cassandra and Cosmos Gremlin you would not use the Azure Cosmos SDK but their respective API libraries.
You can also watch video where I talked on same topic
(The opinions expressed here represent my own and not those of my current or any previous employers.)
