6.1 Semi-Structured Data Storage Design
Key Takeaways
- Azure Cosmos DB offers six APIs (NoSQL, MongoDB, Cassandra, Gremlin, Table, PostgreSQL); pick MongoDB/Cassandra/Table/Gremlin only when migrating an existing workload, and NoSQL for new cloud-native apps.
- A high-cardinality partition key (e.g., customerId) spreads RU/s evenly across physical partitions; a low-cardinality key (e.g., orderStatus) creates a hot partition that throttles no matter how much throughput is provisioned.
- Cosmos DB offers five consistency levels from strongest to weakest: Strong, Bounded Staleness, Session (default), Consistent Prefix, and Eventual.
- Strong consistency cannot be used on accounts configured for multi-region writes, because it cannot guarantee zero RPO/RTO across concurrently writable regions.
- Session consistency is the default and the correct choice for most user-facing apps that need read-your-writes behavior without paying Strong consistency's latency and availability cost.
Why Semi-Structured Data Storage Decisions Matter on AZ-305
Modern cloud-native applications rarely store data in neat rows and columns. Product catalogs, user profiles, IoT telemetry, and session state are natural fits for semi-structured data — data with self-describing structure (like JSON) but without a rigid schema enforced ahead of time. On AZ-305, the "Recommend a solution for storing semi-structured data" objective sits inside the Data Storage domain (20-25% of the exam), and nearly every scenario funnels toward one service: Azure Cosmos DB. You are not tested on writing Cosmos DB queries — you are tested on choosing the right API, designing a partition key that will not throttle under load, and picking the weakest consistency level the application can tolerate.
Azure Cosmos DB: One Engine, Six APIs
Azure Cosmos DB is a fully managed, globally distributed NoSQL (and now also relational and vector) database. Rather than forcing every workload through one data model, Cosmos DB exposes multiple wire-protocol-compatible APIs so teams can either build cloud-native or migrate an existing workload with minimal code change.
| API | Data model | Best fit |
|---|---|---|
| NoSQL (formerly SQL API) | JSON documents, native SQL-like query syntax | New cloud-native apps; full access to Cosmos DB's native feature set (change feed, vector search) |
| MongoDB | BSON documents, MongoDB wire protocol | Migrating an existing MongoDB app with minimal driver changes |
| Cassandra | Wide-column, CQL | Migrating Apache Cassandra workloads that need global distribution without operating a cluster |
| Gremlin | Property graph | Graph/relationship-heavy problems: social networks, recommendation engines, fraud detection |
| Table | Key-value | Modernizing existing Azure Table Storage apps that need higher throughput SLAs and global distribution |
| PostgreSQL | Distributed relational (Citus-based) | Relational workloads that need horizontal scale-out beyond a single Azure SQL/PostgreSQL instance |
Exam framing: if the scenario says "existing MongoDB application, minimize code changes, needs global distribution" → API for MongoDB, not NoSQL. If it says "greenfield app, needs the richest native feature set" → NoSQL API. Matching the verb in the scenario (migrate vs. build new) to the API is the fastest way to eliminate two of the four answer choices.
Partitioning: The Design Decision That Makes or Breaks Cosmos DB
Every Cosmos DB container is split into logical partitions, each identified by a partition key value, and logical partitions are distributed across physical partitions that Azure manages automatically behind the scenes. Throughput (measured in request units per second, or RU/s) is spread across those physical partitions, not shared as one unlimited pool.
A well-chosen partition key:
- Has high cardinality (many distinct values) so writes and reads spread evenly across physical partitions.
- Keeps items that are queried together in the same partition, avoiding expensive cross-partition fan-out queries.
A poorly chosen key creates a hot partition. For example, partitioning an order-processing container by orderStatus — which might only have four or five distinct values such as pending, shipped, and delivered — concentrates nearly all writes for "pending" orders onto a single physical partition. No amount of additional provisioned RU/s at the container level fixes this, because RU/s allocation is capped per physical partition, not simply totaled across the container. The correct fix is a higher-cardinality key such as customerId, or a synthetic composite key like customerId-orderDate when a single field isn't selective enough on its own.
Consistency Levels: Trading Freshness for Speed
Cosmos DB is unusual among distributed databases in offering five consistency levels instead of a simple choice between "strong" and "eventual":
| Level | Guarantee | Typical use |
|---|---|---|
| Strong | Reads always return the latest committed write (linearizable) | Regulatory or financial data where every reader must see an identical value instantly |
| Bounded Staleness | Reads lag writes by at most K versions or T time, whichever comes first | Near-real-time global apps that need a predictable, configurable staleness bound |
| Session (default) | The writer's own session always reads its own writes | The overwhelming majority of user-facing apps — "read-your-own-writes" behavior |
| Consistent Prefix | Reads never see out-of-order writes | Feeds or logs where relative order matters but absolute freshness doesn't |
| Eventual | No ordering guarantee at all | Counters such as likes or view counts, where any stale read is acceptable |
Two exam-relevant traps show up repeatedly:
- Strong consistency cannot be used with multi-region write accounts. A globally distributed system with multiple writable regions cannot guarantee a zero recovery-point objective (RPO) and zero recovery-time objective (RTO) at the same time — pick Bounded Staleness or Session instead when the scenario mentions multi-region writes.
- Session is the practical default for almost every scenario that doesn't explicitly call out a regulatory need for strong consistency. It delivers read-your-writes behavior at close to eventual-consistency latency and throughput, which is why it's the account default.
Scenario Walkthrough
A retail company is building a new order-tracking microservice. Orders must be globally distributed for low-latency reads in the US, Europe, and Asia. Each customer's mobile app must immediately see their own order updates after placing them, but strict global ordering across all customers is not required.
Design: Cosmos DB for NoSQL API (this is a greenfield app, not a migration), partition key = customerId (high cardinality, and it keeps a given customer's orders together for efficient point reads), consistency level = Session (satisfies "customers immediately see their own updates" without paying the latency and availability cost of Strong consistency across three continents).
Key Takeaways Recap
Choosing a Cosmos DB API is fundamentally a migration-cost decision; choosing a partition key is a throughput-distribution decision; choosing a consistency level is a latency-vs-freshness decision. All three show up independently across AZ-305 scenarios, and a well-written scenario question will frequently test two of the three at once — for example, naming both a migration source and a freshness requirement in the same paragraph.
A globally distributed e-commerce application writes to Cosmos DB from three Azure regions simultaneously (multi-region writes are enabled). Which consistency level is unavailable for this account, regardless of application requirements?
A company needs to migrate a Cassandra-based application to Azure without rewriting its CQL queries or replacing its driver, while gaining Cosmos DB's global distribution and SLAs. Which Cosmos DB API best fits this requirement?
A container's partition key is set to region, which has only 5 possible values across a global deployment. Despite the container having ample total provisioned throughput, writes for the busiest region are consistently throttled. What is the root cause and best fix?