Azure Cosmos DB is a globally distributed NoSQL database family with APIs, consistency choices, partitioned scale, and request-unit-based capacity models. Successful design starts with access patterns and a high-cardinality partition key that spreads storage and throughput. A poor partition key can create hot partitions that higher total throughput does not fix.
Lab: 45 minutes · Cost: provisioned/autoscale throughput or serverless requests, storage, backup, regions, and egress can charge · Cleanup: remove the account after the lab.
Denormalize related data that is read together, while respecting item-size and update patterns. Identify:
An item ID plus partition key enables an efficient point read. Cross-partition scans can consume far more request units.
A strong key has many values, distributes request and storage load, appears in common queries, and does not concentrate one “celebrity” tenant. Hierarchical partition keys can help certain multi-tenant models. Synthetic keys can combine fields when no natural key works.
Changing the partition strategy after scale usually requires migration. Prototype it with realistic skew, not uniform test data.
Cosmos DB offers a spectrum including strong, bounded staleness, session, consistent prefix, and eventual consistency, with feature/API qualifications. Session consistency is a common application default because a client sees its own writes while retaining useful scale. Choose from business correctness, latency, region topology, and availability—not from the strongest-sounding label.
Ways to build
Choose the Azure tool you want to use. The underlying resource stays the same.
Search Azure Cosmos DB → Create, select the correct API, capacity mode, region, availability zone/geo choices, backup policy, encryption, and network access. Then open Data Explorer and create a database and container with the /tenantId partition key and reviewed indexing policy.
Request units normalize CPU, I/O, and memory cost for operations. Point reads are cheaper than broad queries; larger items and complex indexing increase consumption. Measure normalized RU consumption per physical partition, throttled requests, query RU, and hot keys.
Use provisioned throughput for steady controlled workloads, autoscale for variable peaks, and serverless where supported for intermittent low-volume work. Test cost at realistic load.
The default indexing policy is broad and convenient. Exclude unused paths or design composite indexes for known query order/filter patterns, but do not prematurely remove indexes. Change feed exposes ordered changes within a logical partition and supports event-driven projections, integration, and processing. Consumers must be idempotent.
Adding regions improves latency and resilience but multiplies cost and introduces consistency/failover decisions. Test regional failover, write-region behavior, SDK preferred regions, conflict handling for multi-write, and dependency alignment. A globally distributed database cannot make a single-region application globally resilient.
Bicep/Terraform should declare account, regions, consistency, database, containers, indexes, throughput mode, network, identity access, backup, diagnostics, and alerts. Do not put account keys in outputs. Prefer RBAC/data-plane roles and managed identity.
Monitor availability, latency, rate-limited requests, normalized RU, storage, replication, and SDK errors. Use the emulator only within its documented behavioral limits.