Azure Cosmos DB

Azure Cosmos DB is a fully managed NoSQL database service that provides turnkey global distribution, elastic scaling of throughput and storage, and multiple consistency models. It is designed for applications that require low-latency reads and writes (<10 ms at the 99th percentile), high availability (99.999% SLA for multi-region writes), and the ability to handle globally distributed data. Unlike traditional relational databases, Cosmos DB is schema-agnostic and stores data as items (documents) in containers, which are analogous to tables. Each item is automatically indexed without requiring schema or secondary indexes.

Cosmos DB uses a distributed storage engine based on a log-structured merge-tree (LSM tree) and a write-optimized indexing subsystem. Data is partitioned horizontally across physical partitions, each responsible for a range of partition key values. The partition key is a property you choose when creating a container; it determines how data is distributed. Each physical partition is replicated across multiple replicas within a region, and for global distribution, replicas are also maintained in other regions. Writes are committed to a quorum of replicas in the write region (for single-region writes) or to the local region (for multi-region writes) and then replicated asynchronously to other regions. The consistency level you choose affects how quickly replicas converge.

You can create a Cosmos DB account using the Azure portal, CLI, or PowerShell. Example CLI command to create an account:

az cosmosdb create --name mycosmosdb --resource-group myrg --kind GlobalDocumentDB --locations regionName=westus failoverPriority=0 isZoneRedundant=false

To create a container:

az cosmosdb sql container create --account-name mycosmosdb --resource-group myrg --database-name mydb --name mycontainer --partition-key-path /id --throughput 400

To verify throughput:

az cosmosdb sql container throughput show --account-name mycosmosdb --resource-group myrg --database-name mydb --name mycontainer

Cosmos DB integrates with Azure Functions for event-driven processing via change feed. The change feed is a persistent log of changes to items in a container, ordered by modification time. You can also use Azure Synapse Link for near-real-time analytics on Cosmos DB data without impacting transactional workloads. Cosmos DB supports multiple APIs: SQL (native), MongoDB, Cassandra, Gremlin (graph), and Table. Each API uses the same underlying engine but different wire protocols and SDKs.

You can provision throughput at the container level (dedicated) or database level (shared). Shared throughput is cost-effective for many small containers but cannot exceed 1000 RUs per container. Minimum throughput for a container is 400 RUs. You can also use autoscale, which scales between 10% and 100% of the maximum RUs you set. The RU cost of a query depends on the query complexity, index usage, and consistency level.

You can add or remove regions at any time with no downtime. For multi-region writes, you enable "Enable multiple write regions" at the account level. Conflict resolution policies (last-writer-wins or custom) handle simultaneous writes to the same item in different regions. The SLA for multi-region writes is 99.999% read and write availability.

Cosmos DB provides encryption at rest and in transit. Access is controlled via primary/secondary keys, read-only keys, or Azure Active Directory (AAD) integration (for SQL API). Firewall rules and virtual network service endpoints are supported. Data is encrypted at rest with Microsoft-managed or customer-managed keys (CMK).

A multinational retailer uses Cosmos DB to store product information (name, price, inventory) across North America, Europe, and Asia. The application requires <10 ms read latency for users worldwide. They deploy Cosmos DB with multi-region writes enabled in three regions: West US, West Europe, and Southeast Asia. The partition key is /productId, which has high cardinality. Throughput is set to 10,000 RUs per container, with autoscale to handle traffic spikes during sales. They use Session consistency for user-facing reads (to see their own writes) and Eventual consistency for background analytics. A common misconfiguration is choosing a partition key with low cardinality (e.g., /category), causing hot partitions and throttling. The solution requires careful partition key design and monitoring via Azure Monitor metrics.

A manufacturing company collects sensor data from thousands of devices. They use Cosmos DB with the MongoDB API to store time-series data. Each sensor sends a JSON document every second. The partition key is /deviceId, and they use a time-to-live (TTL) of 30 days to automatically expire old data. They provision 50,000 RUs for the container to handle peak ingestion. Since data is append-only, they use Eventual consistency for writes to minimize latency. The change feed triggers an Azure Function that aggregates data into a separate container for reporting. A common issue is exceeding the 20 GB partition size limit if a single device sends too much data; they mitigate by adding a synthetic partition key (e.g., /deviceId + /date).

A gaming company uses Cosmos DB with the Gremlin (graph) API to manage player relationships and leaderboards. The graph contains vertices (players) and edges (friendships, scores). They use Strong consistency to ensure leaderboard accuracy. The partition key is /gameId. Throughput is set to 5,000 RUs. They use multi-region writes to support players in the US and EU. A misconfiguration is using the default Session consistency, which can cause stale leaderboard reads. They also need to handle conflict resolution for simultaneous score updates; they use last-writer-wins with a timestamp.