Cassandra vs MongoDB for System Design Interviews

Side by side

Dimension	Cassandra	MongoDB
Data model	Wide-column tables shaped around access patterns	BSON documents with nested fields and arrays
Query flexibility	Partition-key queries are the foundation; indexes add options	Secondary indexes and aggregation support varied queries
Write routing	Any node can coordinate writes to the owning replicas	Writes go to the primary of the owning shard's replica set
Consistency controls	Per-operation consistency levels; lightweight transactions for conditional updates	Read concern, write concern, read preference, and transactions
Horizontal scaling	Token-based partition distribution across nodes	Sharded collections using range or hashed shard keys
Multi-region behavior	Local writes in multiple regions; conflict and consistency trade-offs	Each shard has one primary; remote writers may cross regions
Transaction scope	Limited atomicity scopes; not general multi-partition ACID transactions	Single-document atomicity and multi-document ACID transactions
Operational pressure	Repair, compaction, tombstones, and partition sizing	Index costs, shard balance, replication lag, and elections

The differences that matter

Cassandra usually starts with the query, then the table. For message history, a partition key such as (conversation_id, time_bucket) and a clustering key such as message_id make bounded history reads efficient. Another access pattern may require another table and duplicated writes. MongoDB can keep a richer document and add compound indexes for different filters and sorts, although those indexes consume storage and increase write work. Cassandra also offers indexing options, but they do not remove the need to reason about partition access and query cost.

The replication model changes failure behavior. Cassandra has no elected write primary, and each operation specifies how many replicas must respond. MongoDB routes writes through a replica-set primary, with elections replacing it after failure. Cassandra can accept writes on both sides of some network partitions at weaker consistency levels; MongoDB's majority side can elect a primary, while the minority cannot independently continue primary writes. Neither behavior is a blanket availability guarantee.

Consistency is a configuration and workload discussion, not simply 'eventual versus strong.' Cassandra quorum reads and writes can provide overlapping replica sets, but ordinary quorum operations are not a substitute for linearizable compare-and-set under concurrency. Lightweight transactions provide conditional coordination at additional cost. MongoDB offers atomic document updates and multi-document transactions, but visibility and durability still depend on read concern, write concern, and read routing. Reading from a secondary can return stale data.

Both systems can scale horizontally, but neither fixes a hot data model automatically. A single high-traffic Cassandra partition remains concentrated on its replica set. A hot MongoDB shard-key value remains concentrated on one shard, and queries without a useful shard key may scatter across shards. Cassandra adds repair, compaction, and tombstone management to the design discussion; MongoDB adds index selection, shard distribution, and the cost of cross-shard queries and transactions.

Choose Cassandra when

Your main workload is sustained event ingestion followed by bounded reads using a known entity key and time range.
You need local write acceptance in multiple regions and can define acceptable staleness and conflict behavior explicitly.
Your access patterns are stable enough to maintain query-specific tables and handle duplicated data reliably.
You can bound partition sizes with time buckets or other partitioning rules, and can operate repair, compaction, and retention safely.

Choose MongoDB when

Your application stores document-shaped entities, such as profiles, listings, or catalog items, with several indexed access paths.
Queries and filters evolve, and creating a new query-specific table for every access pattern would add substantial application complexity.
You need atomic updates within a document or genuine multi-document transactions, while accounting for cross-shard coordination costs.
Primary-based writes fit your regional topology, and you want to choose read visibility and durability guarantees for each operation.

A worked example

Chat history versus searchable message records

Suppose a chat service expects 100,000 messages per second, retains history for 30 days, and usually fetches the latest 50 messages from one conversation. Cassandra is a reasonable candidate: partition by conversation and time bucket, cluster by message ID, and size buckets to bound partitions. Extremely busy conversations may still need additional bucketing. Now suppose the main requirement is searching message records by sender, moderation status, attachment type, and time, with filters changing frequently. MongoDB's compound indexes and aggregation become more useful, though sharding must still avoid expensive scatter-gather queries. These are hypothetical requirements, not throughput guarantees for either database.

In the interview

Start with two concrete queries, expected write volume, retention, and item size. Show the Cassandra partition and clustering keys or the MongoDB document, shard key, and compound indexes before naming a winner.
Separate durability, freshness, and availability. State which acknowledgments make a write successful, where reads go, and what happens during a replica failure or regional partition.
Identify the invariant that needs coordination. An append-only message history has different requirements from a unique reservation or a balance update; explain whether conditional writes, transactions, or a separate transactional store are needed.
Expect follow-ups about hot tenants, oversized partitions or documents, query fan-out, and resharding. Explain how you would bound each operation and how adding capacity changes data placement.

Common mistakes

Calling Cassandra always available and MongoDB always strongly consistent. Actual behavior depends on topology, consistency settings, read routing, and the failure being considered.
Claiming Cassandra cannot use secondary indexes or MongoDB cannot scale horizontally. Both claims skip the real question: whether the chosen indexes and partitioning scheme serve the workload efficiently.
Treating Cassandra quorum writes as general-purpose transactions, or assuming MongoDB transactions make distributed coordination inexpensive.
Choosing from a generic write-speed comparison without modeling indexes, replication, document size, skew, retention, and the required failure guarantees.

Where it comes up

Interview questions where choosing between Cassandra and MongoDB comes up.

Questions people ask

Is Cassandra faster than MongoDB?

There is no workload-independent winner. Cassandra is often a candidate for sustained writes and partition-key reads, while MongoDB can serve indexed document queries efficiently. Compare using your item sizes, indexes, replication settings, consistency requirements, and skew, including tail latency during failures and maintenance.

Is Cassandra AP and MongoDB CP?

Those labels are shorthand, not complete descriptions. Cassandra can favor availability with weaker consistency levels, while quorum requirements can reject operations during a partition. MongoDB uses primary-based writes and majority-based elections, but read freshness and write rollback risk still depend on read and write settings. In an interview, describe the actual network partition and which operations succeed.

Should I use Cassandra or MongoDB for a chat app?

Cassandra is a strong candidate for large message histories accessed by conversation and time, provided partitions stay bounded. MongoDB can fit richer conversation metadata and message records that need varied indexed queries. Either choice still needs a design for message ordering, retry deduplication, delivery acknowledgments, and hot conversations.