How it works
Cassandra uses a peer-to-peer architecture for ordinary reads and writes, without a single primary. A client can contact any node, which acts as the coordinator for that request. Token-aware drivers usually route requests directly to a replica to reduce extra network hops.
The partition key is hashed into a token, typically using the Murmur3 partitioner. Token ranges determine ownership, and virtual nodes let each physical node own multiple ranges. The replication strategy selects additional replicas, with NetworkTopologyStrategy accounting for data centers and racks.
Each replica records a write in its commit log and updates an in-memory memtable. Memtables later flush to immutable SSTables on disk. Compaction merges SSTables and removes obsolete data when safe; this LSM-tree design makes the write path efficient but creates background disk work and write amplification. Acknowledgment durability also depends on the commit-log sync configuration.
Reads use in-memory data and relevant SSTables. Bloom filters help skip SSTables that cannot contain the requested partition, while indexes help locate data within files. The coordinator requests enough replica responses for the selected consistency level and reconciles conflicting versions, generally using timestamps.
The data model starts with queries, not normalized entities. A partition key groups related rows, while clustering columns order rows within that partition. Applications often maintain several denormalized tables for different access paths; CQL looks like SQL but does not provide relational joins or arbitrary efficient queries.
What it gives you in a design
- Per-operation consistency levels
- Choose how many replicas must respond to a read or write, such as ONE, LOCAL_QUORUM, or ALL. Stronger acknowledgment requirements usually increase latency and reduce availability during failures.
- Ordered reads within a partition
- Clustering columns support efficient ranges such as messages in a conversation ordered by time. They do not create a globally ordered index across all partitions.
- Topology-aware replication
- Configure replication independently for each data center and distribute replicas across racks. This supports local request handling and regional resilience, but local consistency levels do not guarantee immediate visibility in other regions.
- TTL and deletion
- Rows or values can expire automatically, which is useful for retained events and time-bounded history. Expiration and deletion create tombstones, so they still consume storage and read work until compaction can safely remove them.
- Lightweight transactions
- Conditional statements such as INSERT IF NOT EXISTS provide linearizable compare-and-set operations within their supported scope. They require consensus and more coordination than ordinary writes, so they should not be the default write path.
- Replica convergence mechanisms
- Hinted handoff, read repair, and scheduled anti-entropy repair help replicas converge after missed writes. Hints are best-effort assistance, not a substitute for repair.
Scaling, replication and failure
Add nodes to distribute token ranges and storage, but allow time and capacity for streaming data to new owners. Virtual nodes improve distribution across machines; they do not split a single partition. A hot or oversized partition remains a problem that usually requires time buckets, additional sharding, or a different key.
Replication increases storage and write traffic. Size for replicated data, compaction headroom, repair traffic, and operation with nodes unavailable, rather than assuming every byte of disk can hold application data. Adding nodes while disks are nearly full can make recovery harder.
For replication factor N, read and write response counts satisfying R + W > N give intersecting replica sets. This is useful for visibility under the relevant assumptions, but ordinary Cassandra operations do not become linearizable transactions just because both use quorum. LOCAL_QUORUM intersects replicas within a data center, not necessarily across data centers.
During failures, requests succeed only if enough eligible replicas remain reachable for their consistency level. A timeout does not prove that a write was rejected: some replicas may already have applied it. Repair must reconcile missed updates before tombstones can be safely purged, or old values can reappear.
Limits and defaults worth knowing
Check the current documentation before relying on an exact value; many of these are configurable.
| Quorum response count | QUORUM requires floor(replication factor / 2) + 1 replica responses. LOCAL_QUORUM uses the replication factor in the coordinator's local data center. |
|---|---|
| Replication factor | Configurable per keyspace, and per data center with NetworkTopologyStrategy. Replication factor 3 is a common design choice, not a universal default or a guarantee of surviving every two-node failure. |
| Tombstone grace period | The table option gc_grace_seconds commonly defaults to 864000 seconds, or 10 days. It is configurable and is not an exact deletion deadline; actual removal depends on compaction and other safety conditions. |
| Commit-log synchronization | In periodic commit-log sync mode, writes can be acknowledged before their records are fsynced. The documented default periodic sync interval is commonly 10000 milliseconds; mode, defaults, and configuration options should be checked for the deployed version. |
Use it when
- The workload has high write volume and predictable queries that can identify a partition or a small bounded set of partitions.
- You need large message histories, event records, or time-series data with explicit bucketing and retention.
- The system must continue serving some operations during node or network failures, and you can state the consistency trade-off.
- You need replicas in multiple regions and can define which operations require local versus cross-region coordination.
Avoid it when
- The core workflow requires frequent atomic transactions across unrelated records, such as transferring balances between accounts.
- Users need flexible joins, ad hoc filtering, or changing query patterns without maintaining additional tables or indexes.
- One key must absorb most traffic, or a single entity's partition grows indefinitely without bucketing.
- The dataset and traffic are modest enough that a relational database would meet requirements with substantially less operational work.
What interviewers ask about it
Follow-ups you can expect once Cassandra is on your whiteboard, and the core of a strong answer.
- How would you choose a partition key for chat history?
- Start with a conversation identifier plus a time bucket, then use message time and a unique tie-breaker as clustering columns. Estimate bytes, rows, and traffic per bucket, and explain how pagination crosses buckets. Very busy conversations may need additional shards, at the cost of merging reads.
- Does replication factor 3 with quorum reads and writes provide strong consistency?
- Two-replica reads and writes have intersecting replica sets, which improves visibility of acknowledged writes under the relevant assumptions. Ordinary quorum operations still use timestamp-based reconciliation and are not a general linearizable transaction mechanism. Use lightweight transactions when a conditional update requires linearizable coordination.
- What happens when a write times out?
- The outcome is uncertain because some replicas may have applied the mutation before the timeout. Design retries to preserve logical identity, timestamps, and expiry semantics where appropriate, and avoid assuming that counters or other non-idempotent operations are safe to repeat.
- Why are repair and tombstones connected?
- A replica that misses a deletion can retain an older value. Repair must propagate the deletion before its tombstone is purged, or the old value may be reintroduced. The repair schedule, maximum outage duration, and gc_grace_seconds setting must be designed together.
- How would you deploy Cassandra across regions?
- Use topology-aware replication and specify the replication factor in each data center. LOCAL_QUORUM can keep normal requests within a region, but remote regions may temporarily serve older data. State the failover freshness requirement and whether any operations justify cross-region coordination.
- How do you diagnose slow reads despite fast writes?
- Check partition sizes, tombstones scanned, SSTables touched, compaction backlog, and disk pressure. Efficient writes do not guarantee efficient reads, especially when queries scan large partitions or many deleted values. Fixing the partition model or retention layout may matter more than adding nodes.
Common mistakes
- Treating CQL like relational SQL and designing tables before listing the required queries.
- Claiming that adding nodes fixes hot partitions, or confusing virtual nodes with application-level partition splitting.
- Calling Cassandra simply an AP database without naming consistency levels, the failure scenario, and which operations remain available.
- Ignoring compaction, tombstones, and repair when estimating storage, latency, and operational cost.
Alternatives
- PostgreSQL
- Choose it when transactions, constraints, joins, and evolving queries matter more than distributing writes across many nodes.
- Amazon DynamoDB
- Choose it when you want a managed partitioned database and accept its service-specific data model, consistency options, limits, and pricing.
- ScyllaDB
- Consider it for a Cassandra-compatible data model and protocol with a different storage-engine implementation. Validate compatibility, operational behavior, and performance against your own workload.
- Apache HBase
- Consider it when ordered row-key range scans and integration with the Hadoop ecosystem are central requirements.
Where it comes up
Interview questions where Cassandra is a natural fit, and why.
- Design a distributed key-value storeCassandra provides a concrete example of partition ownership, replica coordination, tunable consistency, and recovery after missed writes.
- Design a chat app like WhatsAppBucketed conversation partitions can store durable message history with bounded, ordered reads.
- Design a metrics monitoring system like DatadogCassandra can store bucketed time-series data when retention, cardinality, and query access paths are explicitly controlled.
- Design a news feed like FacebookDenormalized per-user feed tables illustrate query-driven modeling, bounded partitions, and the cost of fan-out writes.
- Design a distributed tracing systemWrite-heavy span storage can use trace-oriented partitions, while searchable attributes usually require separate access paths or indexing.
Questions people ask
What is Cassandra architecture?
Cassandra has a peer-to-peer architecture in which any node can coordinate a request. It distributes partitions by hashing their keys, replicates them across nodes, and stores data using memtables and immutable SSTables. Clients choose consistency levels that determine how many replicas must respond.
Is Cassandra a columnar database?
Cassandra is usually described as a wide-column database, not an analytical columnar database. Its tables organize rows into partitions with optional clustering order. It is not designed to replace column-oriented analytics engines for broad scans and aggregations.
Is Cassandra eventually consistent or strongly consistent?
Cassandra offers tunable consistency rather than one universal setting. Ordinary reads and writes can favor availability or require quorum responses, while replicas converge through reconciliation and repair. Lightweight transactions provide linearizable conditional operations, but ordinary quorum reads and writes are not equivalent to general serializable transactions.