Interactive guide · 4 chapters · ~12 min read
Cassandra Interview & Revision
Cassandra interview questions tend to circle consistency levels, tunable trade-offs, and the absence of joins — this section condenses those into revision notes, a self-check quiz, and a cheat sheet for last-minute review.
Mangesh MandlikLast updated:
01 · Interview prep
Interview Questions
The questions that come up most often in system design and database-focused interviews about Cassandra.
Q: Why is Cassandra described as masterless?
Every node can coordinate any request — there's no primary node whose failure requires an election or failover. Any node hashes the partition key, finds the owning replicas via the token ring, and routes the request.
Q: How does Cassandra decide which node stores a given row?
It hashes the row's partition key to a token, then walks clockwise around the ring to the first node whose token is ≥ that hash — that node (and the next RF-1 nodes clockwise) store the row.
Q: What happens if a replica is down during a write?
The coordinator writes to the available replicas and stores a 'hint' for the down replica (Hinted Handoff), replaying it once that node recovers — assuming the outage is shorter than the hint window.
Q: What's the difference between Replication Factor and Consistency Level?
Replication Factor (RF) is a keyspace setting — how many copies of each row exist. Consistency Level (CL) is a per-query setting — how many of those copies must respond before the query is considered successful.
Q: How do you guarantee read-your-writes in Cassandra?
Satisfy the R + W > RF overlap condition — e.g. QUORUM writes and QUORUM reads with RF=3 (2 + 2 > 3) means the read and write replica sets must share at least one node, so a read will very likely observe the latest acknowledged write. This is a quorum-overlap condition, not an absolute guarantee — it doesn't by itself provide linearizability; for that, use lightweight transactions (LWT).
02 · Revision
Revision Notes
The core mental model, compressed.
Placement: partition key → hash → token → clockwise node on the ring owns it (plus RF-1 more clockwise for replicas).
Consistency: every read/write picks a CL (ONE / QUORUM / ALL) — this is the actual lever for the consistency/availability trade-off, not a global cluster setting.
Healing: hinted handoff covers short outages; read repair fixes staleness opportunistically during reads; anti-entropy repair (nodetool repair) is the scheduled, comprehensive fix — needed within gc_grace_seconds to reduce the risk of tombstone resurrection.
Coordination: gossip is how nodes learn about each other's health and membership without a central registry — it's what makes the masterless design operationally possible.
03 · Self-check
Quiz
Test yourself before moving on — answers are inline, no peeking until you've thought it through.
1. With RF=3, what CL guarantees a majority of replicas ack a write?
QUORUM — ⌊3/2⌋ + 1 = 2 replicas.
2. True or false: adding a node to a Cassandra ring requires rehashing the entire dataset.
False. Consistent hashing means only the slice of data between the new node and its neighbors moves.
3. What mechanism handles a replica that was down for only a few minutes during a write?
Hinted Handoff — the coordinator stores the missed write and replays it once the replica returns, avoiding a full repair.
4. Which CAP theorem corner does Cassandra default toward?
AP-leaning by default (Availability + Partition tolerance) — it keeps serving requests through a partition and reconciles afterward, but consistency is tunable per query (CL=QUORUM/ALL, or LWT), not fixed.
5. What's a common symptom of a poorly chosen partition key?
Hot partitions — a small number of nodes carry disproportionate load and latency while the rest of the cluster sits idle.
04 · Quick reference
Cheat Sheet
The fastest possible refresher, right before an interview or a production incident.
textCore concepts at a glance
Architecture : Peer-to-peer, masterless, every node identical
Data model : Wide-column, partition key + clustering columns
Placement : hash(partition key) -> token -> clockwise node on ring
Replication : Replication Factor (RF) — copies per row (RF=3 common)
Consistency : Consistency Level (CL) — ONE / QUORUM / ALL, per query
Read-your-writes : R + W > RF quorum-overlap condition (e.g. QUORUM + QUORUM, RF=3) -- not full linearizability; use LWT for that
Membership : Gossip protocol — random peer exchange, exponential spread
Short outage fix : Hinted Handoff (expires after configurable window, default 3h)
Opportunistic fix : Read Repair — triggered by reads, compares timestamps (not comprehensive)
Scheduled fix : Anti-entropy Repair — nodetool repair, Merkle trees (comprehensive)
CAP default : AP-leaning (tunable per query via CL; LWT for CP-like semantics)
Best for : High write throughput, multi-DC availability, time-series/events
Avoid for : Strict multi-row ACID transactions, ad-hoc joinsKey takeaways
- 01State the placement chain from memory: partition key → token → clockwise owner, plus RF-1 further replicas.
- 02RF is a keyspace-level copy count; CL is a per-query acknowledgement count — mixing them up is the most common interview error.
- 03Read-your-writes needs
R + W > RF(QUORUM + QUORUM); that is overlap, not linearizability — name LWT/SERIALfor the stronger case. - 04Name the three repair layers in order of scope: hinted handoff (short outages, 3 h window), read repair (opportunistic),
nodetool repair(comprehensive, withingc_grace_seconds). - 05Default posture is AP-leaning but tunable; avoid it for strict multi-row ACID and ad-hoc joins.