Azure Cosmos DB

What it is

Azure Cosmos DB is a fully managed, globally distributed NoSQL and vector database. In the common API for NoSQL model, an application stores JSON items in a container inside a database. A partition key determines how items and request load are distributed.

Why it exists and prerequisites

It supports applications that need flexible JSON data, fast operational reads and writes, and elastic or global distribution without operating database servers. The team still designs the data model, partition key, throughput, consistency, authorization, and recovery strategy.

Mechanics, relationships, and decisions

The SDK sends a data-plane request to a container or item; Cosmos DB routes it using the partition key and applies the chosen consistency behavior. A well-chosen key spreads traffic and data; a poor one can create a hot partition. Stronger consistency can require more coordination, while weaker options can improve responsiveness and scale. Choose based on what stale reads would mean for the workload.

Throughput is measured in request units (RUs). A point read using the item ID and partition key is generally efficient; cross-partition queries can consume more throughput. Cosmos DB offers provisioned, autoscale, and serverless throughput models, but capacity and cost still depend on the data model and requests.

The change feed lets a processor react to changes in a container. The handler must tolerate retries and avoid unsafe duplicate side effects. It is not a global, exactly-once event log across every partition.

Cosmos DB is not Blob Storage: Cosmos DB models queryable operational items, while Blob Storage stores object content. Cosmos DB is also not automatically the best fit for highly relational workloads or large-scale analytical processing.

Worked example and route

Northwind stores each order as a JSON item with a customer-aware partition key, then uses point reads for the customer-order screen. A change-feed processor starts fulfillment work after an order changes. The handler records an idempotency key so a retry does not create two shipments. This appears after programming/JSON and before AZ-204 event integration.

Re-audit

📘 Sources: Microsoft Learn — Azure Cosmos DB overview, consistency levels, and change feed.