When should you choose Cassandra over other databases?
Choose Cassandra for high write throughput, linear scaling and always-on availability. Learn its best-fit workloads and when SQL or MongoDB fits better.
Expected Interview Answer
Choose Cassandra when you need massive write throughput, linear horizontal scalability, always-on high availability across multiple data centers, and predictable low-latency access by known keys — and when you can accept tunable eventual consistency instead of strict ACID transactions.
Cassandra's masterless, peer-to-peer architecture has no single point of failure and scales writes linearly by adding commodity nodes, making it ideal for time-series, event logging, IoT, messaging, and globally distributed workloads. It is a poor fit when you need ad-hoc queries, complex joins, strong transactional guarantees, or aggregate analytics — those favor relational databases or, for flexible documents, MongoDB. The decision hinges on access patterns, scale, availability needs, and consistency tolerance.
- Linear write scalability across commodity nodes
- No single point of failure (masterless design)
- Multi-data-center and geo-distributed replication
- Tunable consistency per query
- Predictable low latency for key-based reads and writes
AI Mentor Explanation
Choosing Cassandra is like fielding a team of eleven equally capable all-rounders instead of relying on one star captain who must be on the pitch for every play. If any player is injured the game continues seamlessly, and adding a substitute instantly strengthens the side — exactly how a masterless cluster survives node loss and scales by adding peers.
Step-by-Step Explanation
Step 1
Profile your access patterns
Confirm reads and writes are mostly by known keys, not ad-hoc queries, joins, or aggregations.
Step 2
Estimate scale and write load
If write throughput and data volume outgrow a single node or vertical scaling, Cassandra's linear scaling helps.
Step 3
Assess availability needs
Choose Cassandra when you need always-on, multi-data-center operation with no single point of failure.
Step 4
Decide consistency tolerance
Ensure eventual/tunable consistency is acceptable; if you need strict ACID transactions, prefer a relational database.
Step 5
Compare alternatives
Weigh MongoDB for flexible documents, relational DBs for transactions and joins, and warehouses for analytics.
What Interviewer Expects
- Clear grasp of Cassandra's masterless, write-optimized design
- Ability to name good fits: time-series, IoT, messaging, logging
- Awareness of poor fits: joins, ad-hoc queries, strong transactions
- Understanding of tunable consistency and CAP trade-offs
- Comparison against relational and document databases
Common Mistakes
- Choosing Cassandra for transactional, join-heavy workloads
- Expecting ad-hoc query flexibility like SQL
- Ignoring the operational cost of running a cluster
- Assuming strong consistency by default
- Using it for small datasets that a single relational node handles easily
Best Answer (HR Friendly)
“Cassandra is the right choice when you have huge amounts of data being written constantly, need the system to stay online across many locations, and are okay with data becoming consistent shortly after rather than instantly. If you need complex reports or strict transactions, a traditional SQL database is usually better.”
Code Example
-- Multi-DC keyspace with replication in two data centers
CREATE KEYSPACE app
WITH replication = {
'class': 'NetworkTopologyStrategy',
'dc1': 3,
'dc2': 3
};
-- Fast write, then a stronger-consistency read when needed
CONSISTENCY LOCAL_QUORUM;
INSERT INTO events (id, ts, payload) VALUES (uuid(), toTimestamp(now()), 'ok');Follow-up Questions
- How does Cassandra's tunable consistency work?
- Why is Cassandra described as masterless and why does that matter?
- When would you pick MongoDB or PostgreSQL instead?
- What workloads are a poor fit for Cassandra?
- How does multi-data-center replication support high availability?
MCQ Practice
1. Which workload is the best fit for Cassandra?
Cassandra excels at high write throughput and key-based access, making time-series and event data an ideal fit.
2. What is a defining feature of Cassandra's architecture?
Every node is a peer, so there is no single point of failure and writes can be accepted anywhere.
3. What consistency model does Cassandra provide?
Cassandra lets you tune consistency per query (e.g., ONE, QUORUM, ALL), trading latency for stronger guarantees.
Flash Cards
Best-fit Cassandra workloads? — Time-series, IoT, messaging, logging, and any high-write, key-access, always-on use case.
Why masterless matters? — No single point of failure; any node accepts writes and the cluster scales linearly by adding peers.
When NOT to use Cassandra? — When you need joins, ad-hoc queries, aggregates, or strict ACID transactions.
What is tunable consistency? — Per-query choice of consistency level (ONE, QUORUM, ALL) balancing latency against strength.