Azure Cosmos DB: Architecture, Scale, Consistency, and APIs
NoSQL models, partitions, global distribution, RU/s, throughput modes, and five compatible APIs
Suggested study time: 85 minutes • Beginner level • Aligned with the DP-900 study guide and official Microsoft Learn documentation
By João Ricardo Dutra••Complete material
1. NoSQL models and the need for flexibility
Relational tables can be too rigid for data whose shape changes frequently, and performance may require substantial tuning. NoSQL is a family of alternatives that includes document, graph, key/value, and column-family stores.
is a highly scalable Azure database service for nonrelational data. It is designed for operational applications rather than simply storing large binary media.
Topic summary
NoSQL services trade a fixed relational structure for data models aligned with documents, relationships, keys, or column families.
2. A fully managed, schema-agnostic service
is a fully managed platform-as-a-service (PaaS). Microsoft provisions servers and performs patching, updates, and backups, leaving the application team to model data and build business logic.
Items in one container do not need identical properties. This schema-agnostic behavior suits evolving records. Microsoft uses the service behind demanding products such as Xbox Live, Microsoft 365, and Azure services, illustrating its intended operational scale.
Topic summary
Cosmos DB combines managed operations with flexible item structures for rapidly evolving, high-scale applications.
3. Account, database, container, and item
The resource hierarchy has four levels. An account is the top Azure resource and can contain multiple databases. A database is a logical namespace for related containers.
A container is the principal storage and scaling boundary. Its settings include partition key, throughput, indexing policy, and optional time to live (TTL). Items are the stored entities and may be called documents, rows, nodes, or edges according to the selected API.
Figure 1 - Account, database, container, and item
Topic summary
The account organizes databases; databases group containers; containers define scale and policy; items hold application data.
4. Partition keys and automatic indexing
A partition key property distributes items into logical partitions. Each logical partition supports up to 20 GB in the referenced material. A strong key has many distinct values and distributes data and requests evenly.
Cosmos DB indexes every item property automatically by default. The service maintains those indexes without requiring an upfront schema, though indexing policy can be configured at container scope. Automatic partitioning and indexing support bursty ingestion and high write throughput.
Figure 2 - Partition keys and automatic indexing
Topic summary
Partition-key quality controls distribution, while automatic indexing makes properties queryable without manual index administration.
5. Global distribution and low latency
Regions can be added to an account, after which Cosmos DB replicates data automatically. Applications can use the nearest regional replica to reduce latency, and multi-region write accounts improve availability for global workloads.
The referenced performance figures describe typical 99th-percentile reads near 4 ms and writes near 5 ms. Actual design must also consider consistency, distance, request cost, and account configuration.
Figure 3 - Global distribution and low latency
Topic summary
Regional replicas bring data closer to users; multiple write regions add availability and globally distributed write capacity.
6. Five consistency levels
Strong returns the latest committed write. Bounded staleness allows a configured lag measured by time or versions. Session guarantees a consistent view within one client session and is the common starting point for transactional applications.
Consistent prefix preserves write order but can return older values. Eventual provides the weakest immediate guarantee and the greatest availability; replicas converge over time. Moving toward stronger consistency can reduce availability or throughput and increase latency.
Level
Guarantee
Strong
Latest write
Bounded staleness
Configured lag
Session
Within client session
Consistent prefix
Ordered writes
Eventual
Converges over time
Topic summary
Choose among Strong, Bounded staleness, Session, Consistent prefix, and Eventual by balancing correctness, latency, throughput, and availability.
7. Request Units, throughput, and cost
Request Units per second (RU/s) normalize the compute, I/O, and memory cost of reads, writes, queries, and deletes. The material uses a 1 KB item read as an approximate one-RU reference, while real cost varies by item, indexing, consistency, and query complexity.
Dedicated throughput reserves capacity for one container. Shared throughput is set at database level and can serve up to 25 containers. Serverless requires no capacity reservation and bills requests, fitting low or unpredictable traffic, but the referenced account model is limited to one Azure region.
Autoscale accepts a maximum RU/s and adjusts provisioned capacity with demand. Use provisioned throughput when global distribution is required and compare dedicated, shared, serverless, and autoscale from workload shape.
Mode
Allocation
Dedicated
One container
Shared
Database, up to 25 containers
Serverless
Pay per request
Autoscale
Scales to configured maximum
Figure 4 - Request Units, throughput, and cost
Topic summary
RU/s is the common performance and billing currency; throughput mode determines reservation, sharing, automatic scale, and regional capabilities.
8. Good fits and important alternatives
Cosmos DB fits high-frequency IoT and telemetry ingestion, gaming profiles and leaderboards, retail catalogs and carts, order pipelines, and personalized web or mobile experiences. These workloads value flexible schema, global reach, and consistently low latency.
Complex joins across many relational tables usually favor . Large historical analytical workloads usually favor or . Store large videos and files in object storage rather than treating Cosmos DB as a media repository.
Topic summary
Use Cosmos DB for globally distributed operational NoSQL data; choose relational, analytical, or object services when their access pattern is dominant.
9. Why the service exposes multiple APIs
An API is selected when the account is created. It defines the data representation, query language, drivers, and client libraries exposed to the application, while Cosmos DB keeps an internal representation beneath that abstraction.
Wire-protocol compatibility helps existing MongoDB or Apache Cassandra applications migrate with fewer code changes and gain managed throughput, global distribution, and service-level capabilities. The five interfaces are NoSQL, MongoDB, Table, Apache Cassandra, and Apache Gremlin.
API
Model / language
NoSQL
JSON / SQL-like
MongoDB
BSON / MQL
Table
Key-value
Apache Cassandra
Column family / CQL
Apache Gremlin
Graph / Gremlin
Figure 5 - Why the service exposes multiple APIs
Topic summary
Choose the account API from the data model, existing skills, drivers, query language, and migration requirements.
10. for NoSQL and MongoDB
for NoSQL is the native and recommended API for new applications. It stores JSON documents and uses a SQL-like query syntax. Older material may call it the SQL API; the name changed in 2023.
Fabric mirroring can replicate operational NoSQL data into without building a pipeline, separating analytics from transactional demand.
for MongoDB works with MongoDB drivers and libraries, stores BSON, and uses MongoDB Query Language (MQL). It is suited to teams with MongoDB skills and migrations that should minimize application changes.
Figure 6 - for NoSQL and MongoDB
Topic summary
NoSQL is the native JSON option with SQL-like queries; MongoDB compatibility preserves BSON, MQL, drivers, and existing expertise.
11. for Table and Apache Cassandra
for Table uses key/value tables compatible with the Azure programming model. PartitionKey plus RowKey identifies a row. Compared with , it adds global distribution, automatic secondary indexes, immediate autoscale, and greater scalability; it is recommended for new large-scale key/value workloads.
for Apache Cassandra supports the column-family model, where rows may contain different columns. It accepts compatible Cassandra tools and Cassandra Query Language (CQL), whose syntax resembles SQL, making it a migration target for existing Apache Cassandra applications.
for Apache Gremlin stores graph data. Vertices represent entities, edges represent relationships, and Gremlin traverses and modifies the graph.
It suits social networks, recommendation engines, fraud detection, and organizational hierarchies, where connections carry as much meaning as the entities. Gremlin operations can add vertices, create labeled edges, filter nodes, and order traversal results.
Figure 7 - for Apache Gremlin
Topic summary
Use Apache Gremlin when graph traversal across vertices and edges is the core access pattern.
13. Hands-on provisioning and exploration
The exercise requires an Azure subscription with administrative access. A useful lab flow creates a resource group and Cosmos DB account, selects the API and capacity model, creates a database and container, chooses a partition key, inserts items, and runs queries.
Inspect request charges, indexing behavior, distribution settings, consistency, TTL, and monitoring. Remove the resource group after testing to prevent ongoing charges.
Topic summary
Hands-on work connects account and API choices to partitions, throughput, queries, request charges, and cleanup.
14. Assessment reasoning and chapter recap
Automatic partitioning is the discriminating feature for bursty telemetry and, with indexing, supports high write scale. Vertices and edges point to for Apache Gremlin. IoT ingestion and real-time operational processing are strong service scenarios.
Key/value tables point to the Table API, especially when scalability and performance beyond Azure are required. Seasonal global retail spikes point to Cosmos DB, and existing Cassandra code points to the Apache Cassandra API.
Topic summary
For DP-900, connect each question to its data model, API compatibility, partitioning, global scale, consistency, or throughput requirement.
