4.2.1. Core Concepts: Global Distribution and Consistency
💡 First Principle: Cosmos DB trades simplicity and cost for global reach and performance guarantees. Unlike traditional databases that charge for storage, Cosmos DB charges primarily for throughput (Request Units)—you're paying for guaranteed performance, not just space.
Consistency Models (Critical Exam Topic!)
The fundamental trade-off in distributed systems is between consistency (everyone sees the same data) and latency (how fast you get a response). Cosmos DB offers five consistency levels allowing you to choose your position on this spectrum:
| Consistency Level | Guarantee | Latency | Use Case |
|---|---|---|---|
| Strong | Linearizable reads | Highest | Financial transactions |
| Bounded Staleness | Reads lag by defined time/versions | High | Need strong but can tolerate lag |
| Session | Consistent within a session | Medium | Most common; great for user sessions |
| Consistent Prefix | No out-of-order reads | Low | Messaging, feeds |
| Eventual | No ordering guarantees | Lowest | Analytics, logs |
Visual: Cosmos DB Global Distribution
Request Units: The Currency
Cosmos DB bills throughput, not operations. A Request Unit (RU) is normalised cost: 1 RU is a point read of a 1 KB item by its id and partition key. Everything else is priced relative to that — a write costs roughly five times a read of the same item, and a query that filters on unindexed properties or returns many rows costs more again.
You provision RU/s (per second). Exceed the allowance and requests are throttled rather than failed outright, which is why sizing is a real design decision rather than a billing detail.
Partition Keys
Cosmos DB spreads data across physical partitions using a partition key you choose. A good key produces many roughly equal partitions with requests spread evenly across them.
A bad key produces a hot partition — one logical partition taking a disproportionate share of traffic while the rest sit idle. Because throughput is divided across partitions, a hot partition gets throttled even though the account as a whole is well under its RU/s limit. Choosing a key with high cardinality and even access is the single most consequential Cosmos DB design decision.
Multi-Region Writes
Replicating to several regions makes reads local by default; writes still travel to the single write region. Enabling multi-region writes lets every region accept writes locally, which is what a globally distributed application needs to keep write latency low — at the cost of having to resolve conflicts when two regions change the same item.
⚠️ Reasoning Tool for consistency: work down from the requirement. "Must never read a stale value" → Strong. "Tolerates a bounded lag" → Bounded Staleness. "A user must always see their own writes" → Session (the default, and the right answer far more often than candidates expect). "Order matters but freshness does not" → Consistent Prefix. "Fastest and cheapest, staleness is fine" → Eventual.
