Apache Cassandra
Cassandra vs RDBMS Trade-offs
Articulate the fundamental architectural and modeling trade-offs between Cassandra and traditional relational databases.
These are not competitors with different feature sets. They make opposite choices on the same questions, and each choice buys something by giving something up.
An RDBMS is like a single, meticulously organized central library with a full card catalog letting you cross-reference anything against anything else, but only one librarian can update the catalog at a time. Cassandra is like a global chain of libraries, each with quick,独立 local checkout counters that never wait for a central authority, at the cost of each branch needing its own pre-organized, purpose-built shelf for every specific type of request you expect people to make.
Key Concepts
1
The five questions.
RDBMS Cassandra
one node holds the truth every node is equal
joins at read time joins done at write time
schema models entities schema models queries
scale up, or shard by hand add a machine
consistent, may be unavailable available, consistency per query2
Why Cassandra cannot offer joins. A join means matching rows that live anywhere in the dataset. In a
cluster those rows are on different machines, so a join is a distributed operation whose cost grows with
the cluster.
3
Rather than offering a slow join, Cassandra offers none, forcing the work to the write path where it is
predictable. That is the trade behind query-first modelling, denormalization, and the missing WHERE
clauses.
WHERE
4
Why an RDBMS cannot easily be always-on. If one node holds the truth, losing it means failing over, and
during the failover writes stop. Synchronous replication to another node makes writes wait for it.
5
Cassandra has no node that must survive. It stays up through node loss and even through a network split,
at the cost of replicas that can disagree until they converge.
6
In CAP terms, and precisely. Cassandra is AP by default and tunable towards C per query. An RDBMS with
synchronous replication is CP. Both statements are about behaviour during a partition — when there is no
partition, both are consistent and available, which is the nuance interviewers listen for.
7
When Cassandra is right. Writes far outnumber reads. The queries are known in advance and do not
change much. The data is large or growing steadily. Downtime is unacceptable. Multiple regions are
required. Time-series, messaging, event logs, IoT.
8
When it is wrong. Ad-hoc queries, reporting, anything where the questions are not known when the
schema is designed. Transactions spanning several entities. Strong uniqueness on more than one field.
Anything where a single Postgres instance would comfortably fit the data — and that covers more systems
than people expect.
9
The answer that lands. Not "Cassandra scales better", which is only sometimes true and skips the cost.
Better: "It gives up joins and ad-hoc queries so that adding a node adds capacity linearly, with no
failover. If my query patterns are fixed and my write rate is high, that is a good trade. If I still need
to ask new questions of the data, it is a bad one."
10
What the interviewer is probing.1. "When is Cassandra the wrong choice?" Probing: whether you can argue against it. Stalls:
"Never." Moves up: when you need joins, ad-hoc queries, strong transactional guarantees across
rows, or your access patterns are unknown.
11
2. "What does it genuinely give you?" Probing: the strengths. Stalls: "Speed." Moves up:
linear write scalability, no single point of failure, multi-datacentre replication, and predictable
latency at very large scale.
12
3. "What is the operational cost?" Probing: honesty. Stalls: "It is managed." Moves up:
repair, compaction tuning, capacity planning and careful data modelling — considerably more than a
managed relational database.
13
4. "How does the modelling mindset differ?" Probing: the summary. Stalls: "It is similar."
Moves up: relational models the data and then queries it; Cassandra models the queries and
duplicates data to serve them.