Design data storage solutions · Topic 3 of 5
Semi Structured Data and Cosmos DB
AZ-305 NoSQL design: choose a Cosmos DB API, consistency level, provisioned autoscale or serverless throughput, partition key and multi region writes.
- 5 min
- Match the API to the existing app. MongoDB vCore gives the best native compatibility.
- Five consistency levels: strong, bounded staleness, session (default), consistent prefix, eventual. Strong cannot be used with multi region writes.
- Throughput: manual, autoscale (10 to 100 percent, about 1.5 times the cost) and serverless (single region).
What it is
Semi structured data (JSON documents, key value items, graphs, time series) fits a NoSQL store. In Azure the flagship is Azure Cosmos DB, a globally distributed, multi model database with single digit millisecond latency and elastic scale. Designing with it means choosing an API, a consistency level, a throughput mode, a partition key and replication.
How it works
Choosing an API
| API | Use |
|---|---|
| Cosmos DB for NoSQL | New apps. The native API, JSON documents with SQL like queries |
| Cosmos DB for MongoDB (vCore) | MongoDB apps needing native compatibility and minimal change. Uses drivers and aggregation pipelines |
| Cosmos DB for MongoDB (RU based) | MongoDB apps that fit the RU model, with less complete compatibility |
| Cosmos DB for Apache Cassandra | Cassandra apps |
| Cosmos DB for Apache Gremlin | Graph data |
| Cosmos DB for Table | Migrating Azure Table Storage with global distribution and higher throughput |
Choose by existing application and driver compatibility. Rewriting an application to a different API is costly, so match the API to what the code already uses.
Consistency levels
Cosmos DB offers five levels, from strongest to weakest.
| Level | Behaviour |
|---|---|
| Strong | Linearizable reads. Highest latency and cost. Not available with multi region writes |
| Bounded staleness | Reads lag writes by at most K versions or T time. Good for ordering with limited lag |
| Session | Default. A client reads its own writes. Best balance for most apps |
| Consistent prefix | Reads never see out of order writes |
| Eventual | Lowest latency and cost. No ordering guarantee |
Strong and bounded staleness reads cost about double the request units. With strong consistency across regions, write latency grows with the distance between regions. Choose session unless a requirement forces something else.
Throughput modes
| Mode | Use |
|---|---|
| Provisioned (manual) | Predictable, steady workloads. You set RU/s |
| Autoscale | Variable or unpredictable load. Scales between 10 percent and 100 percent of a maximum RU/s. Costs about 1.5 times the manual rate per RU/s, so it saves money when average utilization is low (below about 66 percent) |
| Serverless | Spiky, low volume, dev and test. Pay per request unit consumed. Single region only |
A request unit (RU) is the normalised cost of an operation. Plan RU/s from your read and write mix and item size. Reserved capacity discounts steady provisioned throughput.
Partitioning
Data is split into logical partitions by the partition key, and logical partitions map to physical partitions.
| Fact | Value |
|---|---|
| Logical partition storage limit | 20 GB |
| Physical partition | Up to 10,000 RU/s and 50 GB |
| Good partition key | High cardinality, even request and storage distribution, appears in your queries |
| Bad partition key | Low cardinality or skewed, such as a status field, causing hot partitions |
If a logical partition could exceed 20 GB, use hierarchical partition keys (up to three levels), which allow the first level to grow beyond 20 GB. A key such as tenantId plus userId or ending with /id often works. Choose the key early, because changing it later means copying the data.
Global distribution and availability
- Multi region reads are enabled by adding regions. Multi region writes allow writes in every region with conflict resolution, but cannot use strong consistency.
- Service managed failover moves the write region automatically when an outage occurs.
- Availability zones within a region improve availability. Cosmos DB provides a 99.999 percent read and write SLA for multi region accounts with the right configuration.
- Backup: periodic (default) or continuous with point in time restore.
- Use change feed for event driven processing and analytical store with Synapse Link for analytics without affecting transactions.
Choosing quickly
| Requirement | Answer |
|---|---|
| Existing MongoDB 6 app, minimal change, managed | Cosmos DB for MongoDB (vCore) |
| Global users, single digit ms latency, JSON | Cosmos DB for NoSQL |
| Unpredictable traffic, avoid over provisioning | Autoscale throughput |
| Read your own writes by default | Session consistency |
| Multi region writes | Any level except strong |
| One tenant could exceed 20 GB | Hierarchical partition keys |
A worked scenario
A gaming company stores player profiles as JSON for users on three continents and needs low latency reads and writes everywhere. The architect picks Cosmos DB for NoSQL with multi region writes in three regions and session consistency, autoscale for the evening peaks, and a hierarchical key of /region and /playerId. Continuous backup gives point in time restore, and the change feed feeds a leaderboard function.
What to remember for the exam
- Match the API to the existing app. MongoDB vCore gives the best native compatibility.
- Five consistency levels: strong, bounded staleness, session (default), consistent prefix, eventual. Strong cannot be used with multi region writes.
- Throughput: manual, autoscale (10 to 100 percent, about 1.5 times the cost) and serverless (single region).
- Logical partitions are limited to 20 GB, physical partitions to 10,000 RU/s and 50 GB. Choose a high cardinality key.
- Hierarchical partition keys lift the 20 GB logical limit.
A scenario with spiky, low volume traffic and a single region points to serverless. Unpredictable but sustained traffic points to autoscale.
How the exam asks about this
- "Migrate a MongoDB app with the least code change." Cosmos DB for MongoDB (vCore).
- "Users must always see their own writes." Session consistency.
- "Writes in every region." Multi region writes without strong consistency.
- "A tenant's data will exceed 20 GB." Hierarchical partition keys.
Common mistakes
Choosing strong consistency by default. It costs more and limits regions.
A low cardinality partition key. It creates hot partitions.
Serverless for a global multi region app. It is single region only.
Rewriting for the NoSQL API when a compatible API exists.
Check yourself
Which consistency level is the default?
Session.
What is the logical partition size limit?
20 GB.
Which throughput mode is single region only?
Serverless.
Topic 3 of 5 in Design data storage solutions
Test yourself on Design data storage solutions
The full Microsoft AZ-305 question bank has 755 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.