Topic 3 of 4
Azure Cosmos DB
The relational model is sometimes too rigid or needs a lot of tuning to perform. Azure Cosmos DB is Azure's NoSQL database, designed for global scale and low latency. The exam asks about its use cases, the consistency levels, and what request units are.
Contents
What is Azure Cosmos DB?
A fully managed NoSQL (PaaS), highly scalable database service for non-relational data.
- Microsoft handles the infrastructure: server provisioning, patching, updates, and backups.
- It's schema-agnostic: items in the same container don't need to share a structure. One can have 5 properties and another 15 different ones.
- It supports multiple APIs to store and manage JSON documents, key-value pairs, column families, and graphs (see the APIs article).
How it organizes data
Account: The top-level Azure resource. An account can manage an unlimited amount of data and provisioned throughput.
Database: A logical namespace that groups related containers.
Container: The primary unit of storage and scaling. This is where you configure the partition key, throughput, indexing policy, and an optional time-to-live (TTL).
Items: The data entities. Depending on the API, they're called documents, rows, nodes, or edges.
Partition key and indexing
Partition key
A property you choose to distribute data across logical partitions of up to 20 GB each. A good key has many distinct values and spreads data evenly, to keep throughput balanced.
Automatic indexing
Cosmos DB creates and maintains indexes on every property by default. You don't need to define a schema or manage indexes manually.
Global distribution and performance
You can add Azure regions to the account at any time and the service replicates the data automatically. Users read from the nearest replica and, with multi-region writes, also write to the nearest one.
99.999%
Availability SLA with multi-region writes
< 10 ms
Guaranteed reads and writes at the 99th percentile
≤ 4 / 5 ms
Typical average read / write latency
Consistency levels
With replicas in several regions, you need to decide how consistent they must be with each other. Cosmos DB offers five levels, from strongest to weakest:
| Level | Guarantee |
|---|---|
| Strong | Every read reflects the most recent write. |
| Bounded staleness | Reads lag behind writes by a configurable interval (time or version count). |
| Session | Consistency is guaranteed within a single client session. The most widely used level. |
| Consistent prefix | Reads never see out-of-order writes but may see stale data. |
| Eventual | Replicas converge over time: the weakest guarantee and the highest availability. |
The trade-off
The stronger the consistency, the more guarantees about what you read; the weaker, the more availability. Session is the most widely used level for both single-region and globally distributed applications.
Request units and throughput modes
Cosmos DB measures capacity in request units per second (RU/s). One RU is roughly the cost of reading a single 1 KB item by its ID and partition key. Every operation (reads, writes, queries, deletes) consumes RUs, so it's a single metric for both performance and cost.
Dedicated
Provisioned throughput reserved exclusively for a single container.
Shared
Provisioned throughput set at the database level and shared across up to 25 containers.
Serverless
Nothing to provision: you pay for the RUs your requests consume. Ideal for intermittent traffic. Limited to a single region.
The autoscale option lets you set a maximum RU/s, and Cosmos DB adjusts capacity within that range based on demand. For multi-region distribution, use provisioned throughput, not serverless.
When to use Cosmos DB (and when not)
IoT and telemetry
Fast ingestion of high-frequency device data, available for near-real-time processing.
Gaming
Player profiles, leaderboards, and stats that need low-latency reads and writes.
Retail and e-commerce
Product catalogs, shopping carts, and order pipelines at any scale.
Web and mobile apps
Personalized experiences, social features, and third-party integrations.
Not a good fit
If the application depends on complex multi-table joins, Azure SQL Database is better suited. For large-scale analytics, Microsoft Fabric.
Exam scenarios
| Situation | Answer | Why |
|---|---|---|
| High-frequency IoT device data available in near real time | Azure Cosmos DB | Fast ingestion and low latency. |
| A game's profiles and leaderboards with low-latency reads and writes | Azure Cosmos DB | A typical gaming use case. |
| Users on several continents reading and writing in the nearest region | Multi-region writes | Low latency wherever they are. |
| Every read must reflect the most recent write | Strong consistency | The strongest guarantee. |
| Consistency guaranteed within each user's session | Session consistency | The most widely used. |
| Intermittent, unpredictable traffic, paying only for what's used | Serverless mode | No provisioned throughput. |
| An application that depends on complex joins across many tables | Azure SQL Database | Cosmos DB isn't the best fit. |
| Share a database's throughput across several containers | Shared throughput | At the database level, up to 25 containers. |
Common exam traps
❓ Must all items in a Cosmos DB container share the same schema?
No. Cosmos DB is schema-agnostic.
❓ Do you have to create indexes manually in Cosmos DB?
No. It automatically indexes every property by default.
❓ What is the most widely used consistency level?
Session.
❓ Which level guarantees that every read reflects the latest write?
Strong.
❓ Can a serverless account be replicated across several regions?
No. Serverless is limited to one region; for multiple regions you use provisioned throughput.
❓ What does one request unit (RU) roughly represent?
The cost of reading a single 1 KB item by its ID and partition key.
❓ What is the primary unit of storage and scaling?
The container, where the partition key, throughput, and indexing are configured.
Did you get this topic?
Test what you just learned
An e-commerce application with users in Europe, America, and Asia needs each user to read and write in the nearest region with millisecond latency. Which Cosmos DB configuration enables this?