A global retail app stores shopping carts and real-time inventory reservations for millions of customers. Product catalog reads are distributed worldwide, but checkout writes must not silently overwrite one another. A team chooses Azure Cosmos DB for its global distribution and then puts every order under a partition key named orders. The service can scale broadly, yet one hot logical key and an unclear consistency policy can still cause throttling, stale reads, or conflicting writes. The architecture starts with actual access patterns and correctness rules.
Microsoft AZ-305 requires designing semi-structured data storage that balances scalability, protection, performance and cost. The Azure storage-at-scale specialist outlines the platform choice. This article goes deeper into Cosmos DB’s partition key, request units, consistency, global regions, and operations. These factors decide whether a NoSQL service meets a workload’s business invariants rather than simply its expected number of records.
Gather queries and write patterns before modeling documents
List the ten most frequent operations: create cart, append line item, list customer carts, lookup order by ID, reserve stock, view recent products, and so on. For each, record the key known to the caller, result size, access frequency, latency, and consistency need. A JSON document shape that looks intuitive is not useful if almost every important request must scan many logical partitions.
Decide which data belongs in one document versus separate documents. A cart often benefits from storing closely related line items together, but unbounded arrays, changing customer history, or frequently updated counters can lead to large documents and contention. The design should minimize multi-item coordination for operations that need to behave as one business transaction, without packing unrelated histories into one enormous record.
Partition around diverse, stable workload identifiers
Cosmos DB uses the partition key to distribute items and request demand across partitions. A key such as customer ID may be a sound choice when most operations address a particular customer and activity is spread reasonably well. A low-cardinality constant, country name, or globally shared date can concentrate writes and reads into hot logical partitions. Compute required throughput at the busiest keys, not only the average across the container.
The Cosmos DB partitioning guidance describes logical and physical partition concepts. A good key supports the required query paths and distributes both storage and throughput. If one celebrity account receives vastly more traffic than others, that skew must be part of the design: adaptive strategies, key changes, or sharding can add complexity, but a popular key cannot be made cold by increasing the number of unrelated users.
Model request units and indexes against real operations
Azure Cosmos DB request-unit consumption depends on the operation and factors such as item size, indexing work, query shape and consistency. A point read using a complete ID and partition key is generally more efficient than a broad query spanning partitions. Write-intensive applications can pay heavily for indexing fields that are never queried. Tune indexing policy to actual queries rather than indexing everything by default out of caution.
Estimate both steady and burst RU demand. Provisioned throughput can suit predictable demand; autoscale can adapt within its configured range where supported; serverless can be attractive for particular intermittent or development patterns. Each comes with constraints and economics that should be confirmed for the API and account configuration chosen. A low average RU figure can conceal one costly cross-partition query that spikes under normal traffic.
Choose consistency from business invariants
Consistency options trade read freshness, latency and availability characteristics. Some applications can tolerate a slightly stale product catalog while an order confirmation may require that the user sees their own committed write. Distinguish consistency of the database operation from higher-level application correctness: retrying a payment after a timeout can still create a duplicate even if the database offers strong reads.
Document which operations require the latest authoritative state and which can accept lag. Session consistency can support common user-centered patterns when session tokens are handled correctly, but a stateless multi-service app needs to verify that the expected session context is actually propagated. Do not promise linearized correctness to every reader across every Region without a design and service configuration that supports the claim.
Design regional reads and writes intentionally
Add Regions to meet explicit latency, business-continuity, data residency, or write-availability requirements, not merely to make an architecture diagram global. Regional replication affects cost and conflict behavior. A single-write-region design has a clearer write authority but different regional outage response from a multi-write configuration. If accepting writes in multiple Regions, define deterministic conflict resolution that preserves domain correctness.
A last-writer-wins rule based on a generic timestamp may be unacceptable for financial balances or scarce inventory reservations. Store explicit versions, conditional operations, or use a different transactional workflow where required. Test a simultaneous update from two distant regions. A conflict that silently resolves to one value may be service-consistent but still violate the customer’s business promise.
Apply lifecycle and security at the data boundary
Use appropriate Microsoft Entra identities or narrowly scoped credentials, configure permitted networks or private access where supported, and review role permissions separately from database connection settings. Sensitive records should be encrypted and access limited by actual tenant authorization as well as service-level credentials. A single app role with database-wide permissions must not become a shortcut for skipping per-customer checks in the application.
The multi-tenant identity design explains how a successful sign-in should not imply access to another tenant’s data. Store tenant context in keys, queries and service authorization consistently. A private endpoint helps restrict network reachability, but it cannot determine which customer may read a cart. Both dimensions need deliberate testing.
Decide when relational data is the better answer
A workflow requiring complex joins, ad hoc relational queries, and tightly coordinated transactions may be a better fit for Azure SQL than a partitioned document store. Cosmos DB can be excellent for predictable, horizontally distributed access but it is not universally faster or simpler. The workload’s transaction, query and operational model should drive the decision. A migration to documents is not a fix for an incorrect data contract.
For an order service, keep strongly consistent financial ledgers in an appropriate transactional store when the domain demands it, while using Cosmos DB for global catalog or cart patterns if justified. Duplication into a read model can improve latency but introduces synchronization, monitoring and data ownership. A clear source-of-truth decision matters more than choosing one product for every dataset.
Test hot keys, failover, and cost together
Generate synthetic traffic that includes one deliberately heavy tenant and many ordinary tenants. Observe throttled requests, RU use, query latency, and retry behavior. Run point reads and equivalent cross-partition queries. Then simulate regional impairment and a conflicting write in a test environment, measuring whether the business outcome remains correct rather than only whether the SDK returns HTTP success.
An AZ-305 NoSQL architecture explains its partition key from real operations, states a defensible consistency level, quantifies read and write demand, protects tenant identity, and specifies recovery and regional-write semantics. Global distribution is a tool for a measured requirement; a database design is sound only when the work remains correct, affordable, and diagnosable at peak demand.