What is Azure Cosmos DB

In this article, I will walk you through everything you need to know about Azure Cosmos DB: its internal architecture, multi-model API ecosystem, consistency levels, partitioning mechanics, capacity planning models, and where it fits into modern enterprise applications.

What is Azure Cosmos DB

Core Architectural Foundations of Azure Cosmos DB

To understand why Cosmos DB performs so well at scale, you have to look beneath the surface at its distributed engine.

The Atom-Record-Sequence (ARS) Engine

Traditional databases are bound to a single data structure—tables for relational databases, documents for BSON/JSON stores, or adjacency lists for graph databases. Cosmos DB approaches data storage differently.

Its underlying storage engine operates on a type-agnostic abstraction called Atom-Record-Sequence (ARS):

• Atoms: Primitive data types such as strings, numbers, and booleans.
• Records: Key-value pairs composed of atoms.
• Sequences: Ordered or unordered arrays of records or atoms.

Because all data is translated into this universal internal representation, Cosmos DB can expose multiple API interfaces on top of the same core database engine without converting formats at runtime.

Automatic, Schema-Agnostic Indexing

In standard relational databases, every index must be explicitly designed, applied, and maintained. By default, Azure Cosmos DB automatically indexes every property in every JSON document without requiring schema declarations or secondary index definitions. While you can customize your indexing policies to optimize write costs, this schema-agnostic approach drastically accelerates agile development cycles.

The Multi-Model API Ecosystem

One of Cosmos DB’s greatest strengths is its ability to support diverse data paradigms. You choose the API that matches your team’s skillset and application requirements while inheriting Cosmos DB’s global distribution and scaling capabilities.

Which API Should You Use?

• Start with the API for NoSQL: For net-new cloud-native applications, Microsoft’s native API for NoSQL is the recommended choice. It receives the newest features first, offers native SDK optimizations in .NET, Java, Node.js, and Python, and provides a SQL query syntax familiar to most developers.
• Use Compatibility APIs for Migrations: If your team already has existing codebases built around MongoDB or Cassandra drivers, using their respective compatibility APIs lets you migrate workloads with minimal changes to your application connection strings.

Tunable Consistency: The 5 Consistency Levels

In a distributed database system, balancing data consistency, latency, and availability is governed by the CAP theorem. Instead of forcing an extreme choice between strict ACID consistency (which increases latency) and eventual consistency (which risks dirty reads), Cosmos DB provides five tunable consistency levels:

[Strong] ---> [Bounded Staleness] ---> [Session] ---> [Consistent Prefix] ---> [Eventual]
<--- Strictest Consistency / Higher Latency            Lowest Latency / Highest Availability --->

Breakdown of the Consistency Models

1. Strong Consistency:
   • Guarantee: Linearizability. Reads are guaranteed to return the most recently committed version of an item.
   • Trade-off: High write latency across geographic regions, as writes must be synchronously acknowledged by a majority of replicas worldwide.
2. Bounded Staleness:
   • Guarantee: Reads may lag behind writes by a specified operational window, defined either by a time duration (e.g., $K$ seconds) or a version threshold (e.g., $N$ updates).
   • Application: Ideal for global tracking systems or financial dashboards that tolerate a controlled, predictable read delay.
3. Session Consistency (Default):
   • Guarantee: Scoped to an active client session. Guarantees monotonic reads, monotonic writes, and read-your-own-writes for the user or thread holding the session token.
   • Application: The default choice for modern web applications, social platforms, and shopping carts where a user expects to see their own updates immediately while other global users catch up asynchronously.
4. Consistent Prefix:
   • Guarantee: Updates are never seen out of order. Readers might see stale data, but they will never witness an orphaned child update before its parent transaction.
   • Application: Ideal for chat applications, commenting threads, and sports score tickers.
5. Eventual Consistency:
   • Guarantee: No ordering guarantees; data converges across all replicas in the absence of further writes.
   • Trade-off: Delivers the lowest read/write latency and highest throughput.

Horizontal Partitioning and Scaling Mechanics

Cosmos DB achieves virtually infinite scale through horizontal partitioning. Understanding this concept is essential for avoiding performance bottlenecks.

Logical vs. Physical Partitions

• Logical Partitions: A logical partition is a subset of items within a container that share the same Partition Key value (e.g., tenantId, customerId, deviceId). A single logical partition can hold up to 20 GB of data.
• Physical Partitions: Azure manages the underlying physical compute nodes and solid-state drives (SSDs). Each physical partition can store up to 50 GB and serve up to 10,000 RU/s. As your dataset expands past 50 GB or your throughput needs exceed 10,000 RU/s, Cosmos DB automatically splits and redistributes logical partitions across new physical nodes without application downtime.

Selecting an Optimal Partition Key

Choosing the right partition key is the single most important design decision in Cosmos DB:

• High Cardinality: Select a key that has thousands or millions of distinct values (e.g., userId, orderId) rather than low-cardinality flags (e.g., gender, status).
• Even Distribution of Throughput: Ensure writes and reads are evenly distributed across all logical partitions to prevent hot partitions (a single partition maxing out allocated throughput while others sit idle).
• Point-Read Alignment: If possible, align your query filters with the partition key to avoid cross-partition queries, which scan multiple physical partitions and consume substantially more Request Units.

Capacity Planning: Request Units (RU/s) vs. vCore Models

Azure Cosmos DB provides two primary provisioning models: the Request Unit (RU) model and the vCore-based model.

The Request Unit (RU/s) Model

For the API for NoSQL, Cassandra, Table, and Gremlin, Cosmos DB abstracts compute, memory, and IOPS into a standardized currency called a Request Unit (RU):

• Baseline Measurement: Fetching a 1 KB document using its unique id and partitionKey costs 1 RU.
• Complex Operations: Complex queries involving sorting, string manipulations, joins, and indexing cost more RUs depending on resource utilization.

The vCore-Based Model

For the API for MongoDB, Azure offers a dedicated vCore-based architecture. Instead of calculating and provisioning RUs, organizations can choose familiar virtual core and RAM configurations (e.g., 2 vCPU / 8 GB RAM, 8 vCPU / 32 GB RAM). This model makes migrating legacy on-premises databases simpler, as infrastructure sizing maps directly to traditional compute instances.

When Should You Choose Azure Cosmos DB?

Cosmos DB is designed for workloads requiring extreme scale, low latency, and global reach.

Ideal Use Case Scenarios

• Global Digital Commerce & Retail: Handling catalog lookups, real-time inventory adjustments, and shopping cart sessions across multi-region storefronts during high-traffic events.
• IoT Telemetry & Time-Series Data: Ingesting millions of sensor pings per second from connected devices across multiple geographic zones without ingestion lag.
• Mission-Critical Microservices: Serving as the state-store for decoupled microservice architectures that require high availability and independent scalability.
• AI Agents & Semantic Search: Powering Retrieval-Augmented Generation (RAG) applications that require high-speed vector retrieval alongside transactional metadata.

Summary

Azure Cosmos DB is more than just a NoSQL store—it is a comprehensive, globally distributed data fabric. By mastering its core architectural pillars—the ARS storage engine, the five tunable consistency levels, efficient partition key design, and capacity allocation models—you can build modern, resilient cloud applications that scale seamlessly to millions of users worldwide.

You may also like the following articles:

• Azure Cosmos DB Pricing
• How to create Cosmos DB in Azure
• What is Cosmos DB good for

Rajkishore

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.