Cosmos DB

Azure Cosmos DB is a globally distributed multi-model database with API choices (NoSQL, MongoDB, Cassandra, Gremlin, Table). Throughput is provisioned in request units (RUs); partition key design drives scalability, cost, and hot-partition risk.

| Knob | Effect | |------|--------| | Partition key | Routes items; poor choice creates hot partitions | | Consistency level | Latency vs staleness across regions | | Autoscale RU/s | Cost control with burst headroom | | TTL | Automatic expiry for ephemeral documents |

					await container.items.create({
  id: userId,
  partitionKey: userId,
  profile: { name: 'Ada' },
});
				

On interviews: partition key selection for a feed or orders table; session vs strong consistency trade-offs; RU charge for queries without partition key; change feed for event projection; and when Cosmos is overkill versus PostgreSQL or Blob Storage.

Common pitfalls: cross-partition scans in hot paths; ignoring 429 throttling signals; multi-region writes without understanding conflict resolution; and provisioning peak RU/s when autoscale would suffice.

The trade-off is global low-latency reads and elastic scale versus modeling rigor, RU cost visibility, and operational learning curve compared to relational stores.

Checklist:

• Choose partition keys from high-cardinality access patterns.
• Align consistency level with business tolerance for staleness.
• Use point reads and partition-scoped queries in hot paths.
• Monitor 429 rate, RU consumption, and partition heat.
• Prove restore and multi-region failover in a staging account.