Database / Azure Cosmos DB interview questions
What is the Cosmos DB Cassandra API and how does CQL map to Cosmos DB concepts?
The Cosmos DB Cassandra API exposes Cosmos DB as a Cassandra-compatible data store using the Cassandra Query Language (CQL) wire protocol. Applications built on Apache Cassandra — using drivers like DataStax Java Driver, Python driver, or the gocql Go driver — can connect to Cosmos DB by changing the endpoint and credentials, without modifying application code.
CQL concepts map to Cosmos DB concepts as follows:
| Cassandra Concept | Cosmos DB Equivalent |
|---|---|
| Keyspace | Database |
| Table | Container |
| Row | Item (document) |
| Partition Key | Partition Key |
| Clustering Column | Part of the item schema (ordering within a partition) |
| Secondary Index | GSI / Cosmos DB index |
Key behavioral differences from native Cassandra to know for interviews:
- Consistency model — Cosmos DB applies its own 5-level consistency model. Cassandra consistency levels in CQL (
LOCAL_QUORUM,ONE, etc.) are accepted by the API but mapped to the account-level Cosmos DB consistency setting, not enforced as true Cassandra quorum reads. - Lightweight Transactions (LWT) — Cassandra's
IF NOT EXISTSandIF conditioncompare-and-swap operations have limited support in Cosmos DB Cassandra API. Full LWT support is not guaranteed. - Tunable throughput — Unlike Cassandra where you scale by adding nodes, Cosmos DB Cassandra uses RU/s provisioning. There is no concept of a Cassandra ring or token range management.
- No compaction or repair — Cosmos DB manages its own storage internally. Cassandra operational tasks like
nodetool compactornodetool repairdo not exist.
In Cosmos DB Cassandra API, what does a Cassandra Keyspace map to?
What happens to Cassandra consistency level settings like LOCAL_QUORUM when used with Cosmos DB Cassandra API?
More Related questions...
