Global Distribution
Cosmos DB can replicate your data to any Azure region with a single click — or configure it programmatically. Key capabilities:
- Multi-region reads — Users automatically routed to nearest region
- Multi-region writes — Write to any region; conflicts resolved automatically
- Automatic failover — If a region fails, traffic moves to next available region
- Manual failover — For testing DR procedures
Five Consistency Levels
Cosmos DB offers five consistency models — from strongest (more consistent, more latency) to weakest (less consistent, less latency/cost). This is unique in the industry and a key exam topic.
| Level | Guarantees | Latency | Use When |
|---|---|---|---|
| Strong | Always reads latest write — linearisable | Highest | Financial transactions, inventory |
| Bounded Staleness | Reads lag behind writes by configurable time or operations | High | Apps tolerating slight lag but needing order guarantees |
| Session (default) | Consistent reads/writes within a session — monotonic | Medium | Most apps — social profiles, shopping carts |
| Consistent Prefix | Reads never see out-of-order writes | Low | Social media feeds, logs |
| Eventual | No ordering guarantee — replicas eventually converge | Lowest | Likes/views counts, non-critical data |
Database APIs
Cosmos DB supports multiple APIs — you can use your existing skills and client libraries:
| API | Use When | Wire Protocol |
|---|---|---|
| NoSQL (SQL) | Native Cosmos DB — JSON documents, SQL-like queries | Cosmos REST API |
| MongoDB | Migrating from MongoDB, existing MongoDB code | MongoDB wire protocol |
| Cassandra | Wide-column data, existing Cassandra apps | Cassandra wire protocol (CQL) |
| Gremlin | Graph data — social networks, recommendation engines | Gremlin (Apache TinkerPop) |
| Table | Migrating from Azure Table Storage, need global distribution | OData (Table Storage compatible) |
Partitioning
Cosmos DB distributes data across partitions for scale. You must choose a partition key when creating a container. Good partition key design is critical:
- High cardinality — Many unique values (userId, orderId) — not gender or country
- Evenly distributed reads/writes — Avoid hot partitions where one key gets all traffic
- Used in most queries — Include partition key in queries for efficiency
Bad Partition Keys status (only a few values), createdDate (hot partition for today's date), country (uneven distribution).
Request Units (RU/s)
Cosmos DB billing is based on Request Units per second (RU/s) — not raw CPU/memory. One RU represents the resources needed to read a 1 KB document. Other operations cost more:
- 1 KB point read: ~1 RU
- 1 KB write: ~5 RUs
- Complex query: 10–100+ RUs
You provision RU/s at the container or database level. If your app exceeds the provisioned RU/s, requests are rate-limited (429 errors) — you need to provision more RU/s or use autoscale.
Throughput Modes
| Mode | Description | Best For |
|---|---|---|
| Provisioned (Manual) | Set fixed RU/s — guaranteed throughput | Predictable, sustained workloads |
| Autoscale | Set max RU/s — scales 10% of max to max automatically | Variable workloads with peak hours |
| Serverless | Pay per RU consumed — no minimum | Dev/test, sporadic workloads |
Change Feed
Cosmos DB's change feed is a persistent log of all changes (inserts, updates) to a container in order. Applications can read this feed to:
- Trigger event-driven processing (Azure Functions)
- Build real-time dashboards
- Replicate data to other systems
- Implement event sourcing patterns
SLA Guarantees
| SLA | Guarantee |
|---|---|
| Availability | 99.999% (5 nines) with multi-region writes |
| Read latency | <10ms at 99th percentile |
| Write latency | <15ms at 99th percentile |
| Throughput | Provisioned RU/s guaranteed |