The Azure CosmosDB is a special case because it is not only a (prefabricated) service offer but also a toolkit with which you can create a service according to your individual needs. Let's have a look at the modular system in detail:

Azure CosmosDB is based on the atom–record–sequence (ARS) data model and is supported by multiple data models.

These include models for:

• Key/value stores: Key/value store is a large table which has a unique key to each data value and its uses this key to store the data by using appropriate hashing function. Most key/value stores only support query, insert, and delete operations. To update a value (partially or completely), a client must overwrite the existing data.
• Document databases: Document database and key/value store are almost similar except that there is a collection of named fields and data called as documents each of which could be simple or compound elements. Encoding of the data in fields are done using XML, YAML, JSON, BSON, or even stored as plain text. Enabling an application to query and filter data is possible using the fields since they are exposed to storage management system. The freeform approach that the document database provides makes it more flexible since the applications store different data in documents as the business requirements changes
• Graph databases: Nodes and edges are two types of information that graph database stores. Nodes can be considered as entities and edges specifies relationships between them. Both nodes and edges can have properties that provide information about that node or edge, similar to columns in a table. Edges can also have a direction indicating the nature of the relationship.

Furthermore, Azure CosmosDB provides support for numerous APIs:

• DocumentDB API
• MongoDB API
• Table API (Azure Storage Table service)
• Graph API (Apache TinkerPop Gremlin)
• Graph API (Apache Spark GraphX)

Further data models and APIs are planned.

Let's go back to the topic of consistency, or rather the consistency model. Distributed database systems typically provide the following two models:

• Strong consistency: Strong consistency provides guaranteed linearization, which means that the readings will definitely return the latest version of an element. In other words, a client can never see an unauthorized or incomplete write operation to ensure that he always accesses the most recent elements.

• Eventual consistency: Eventual consistency ensures that the replication within the group ultimately leads to convergence in the absence of further writes. The eventual consistency level represents the weakest form of consistency, where a client may retrieve older values than those previously displayed. The eventual consistency layer provides the weakest read consistency, but the lowest latency for read and write operations.

Azure CosmosDB also provides the following models:

• Bounded staleness: The consistency level, bounded staleness, ensures that read operations that are against writing operations are less than a factor of K for the number of versions, or the factor T as a time interval. Bounded staleness is particularly recommended for globally distributed applications, with scenarios that require high consistency, but also 99.99% availability and low latency. 

• Session: Unlike the other consistency models, the consistency level, session is only scoped to a client session. The sessions level guarantees monotonic reads, monotonic writes, and read-your-own-writes (RYW) guarantees. This gives you a predictable consistency for your session, a maximum readability, and a read and write speed with a low latency.

• Consistent prefix: The consistency level, consistent prefix, guarantees, in the absence of further writing operations, that the replicas within the group ultimately come to convergence. It is also ensured that no write operations are displayed outside the specified sequence during read operations. When writing is done in the order A, B, C, the client displays A, A, B or A, B, C and does not display an A, C, or B, A, C sequence.