Apache Cassandra
5.xSummary
Wide-column distributed database with linear write scalability, tunable consistency, and no single point of failure, designed for multi-datacenter deployments requiring always-on availability under network partition.
Primary Use Case
High-throughput write-heavy workloads requiring multi-datacenter replication, time-series data storage, and predictable low-latency at massive scale where eventual consistency is acceptable.
Workload Fit
Strengths
Best for
- ·Write-heavy workloads requiring linear scaling beyond single-primary limits
- ·Time-series data with time-based partition keys enabling efficient range queries
- ·Multi-datacenter deployments with active-active replication
- ·IoT telemetry ingestion at very high write rates with predictable access patterns
Excels when
- ·Write throughput exceeds what a single PostgreSQL primary can handle
- ·Multi-region active-active is a hard requirement
- ·Access patterns are narrowly defined by partition key (no ad-hoc queries)
- ·Team has dedicated Cassandra expertise
Architectural advantages
- ·No single point of failure: every node in the ring is equal
- ·Tunable consistency enables per-operation trade-off between consistency and availability
- ·Multi-datacenter topology with NetworkTopologyStrategy enables geographic distribution
- ·Linear write scaling: adding nodes increases write throughput proportionally
- ·Excellent write throughput: writes are sequential appends to the commit log and memtable, with no read-before-write and no random I/O on the write path
When to Avoid
Avoid when
- ·Workload requires ad-hoc queries across non-partition-key dimensions: Cassandra cannot do this efficiently
- ·Team lacks dedicated Cassandra expertise: operational complexity is the highest of any common datastore
- ·Data access patterns are unknown or evolving: schema changes in Cassandra are disruptive
Common misuses
- ·Modeling data like a relational database: Cassandra requires denormalization and access-pattern-first design
- ·Using Cassandra for OLAP aggregations: full-cluster scans are prohibitively expensive
- ·Ignoring repair: clusters run without repair degrade silently until a node replacement reveals inconsistencies
Consistency & Transactions
Scaling
Read scalability
Reads are served from the node(s) responsible for the partition key. Consistency level LOCAL_QUORUM provides strong consistency within a DC. Read performance degrades with tombstone accumulation and wide partitions.
Write scalability
Writes are appended to commit log and memtable: no read-before-write for standard inserts. Linear write scaling as nodes are added. Gossip protocol keeps cluster topology synchronized across all nodes.
Failure Behavior
Known failure modes
- ·Tombstone accumulation: deleted rows leave tombstone markers that degrade read performance and must persist until gc_grace_seconds elapses across all replicas before compaction purges them
- ·Wide partition: partitions exceeding 100MB+ cause GC pressure and read latency degradation
- ·Compaction debt (lsm_compaction_debt): heavy write workloads generate SSTables faster than compaction can merge them, increasing read and space amplification
- ·Read amplification (read_amplification): a point read may need to check the memtable plus multiple SSTables before finding the current value; Bloom filters and partition summary indexes reduce but do not eliminate this cost
- ·Repair gaps: without regular nodetool repair, inconsistencies accumulate silently
- ·Schema disagreement: failed schema changes leave cluster in partial state
Bottlenecks
- ·Read performance degrades with tombstone accumulation from frequent deletes/updates
- ·Wide partitions (>100MB) cause GC pressure and compaction overhead
- ·Compaction falling behind under sustained high write rate (lsm_compaction_debt): SSTables accumulate faster than compaction can merge them, increasing read and space amplification
Degradation patterns
- ·Tombstone accumulation from delete-heavy or TTL-heavy workloads increases the number of tombstones a read must skip past, degrading read latency until gc_grace_seconds elapses and compaction purges them
- ·Compaction lag (lsm_compaction_debt) causes SSTable count growth, increasing read amplification and read latency
- ·Repair gaps manifest as stale reads when a repaired node serves requests for unrepaired ranges
Recovery considerations
- ·Node failure recovery requires bootstrap or replace operation; data is re-replicated from ring peers
- ·Regular nodetool repair is required to prevent inconsistency: not automatic
- ·Schema changes require cluster-wide coordination: failed changes leave schema in disagreement state
Operational Pitfalls
- ·Not running regular nodetool repair: inconsistencies accumulate silently and manifest during node replacement
- ·Using ALLOW FILTERING on non-partition-key columns: causes full-cluster scans
- ·Designing wide partitions: partitions exceeding 100MB are an anti-pattern causing compaction and GC issues
- ·Using Cassandra for low-cardinality, aggregation-heavy analytics: it is optimized for partition key access, not scans
Architecture Guidance
Common topology roles
Migration notes
- ·From PostgreSQL: requires complete data model redesign: Cassandra does not support relational access patterns
- ·To Amazon Keyspaces: CQL-compatible but feature subset: validate advanced Cassandra features before migration
- ·Migrating away from Cassandra: tombstone-heavy tables require TTL cleanup before migration export
Advisor Guidance
When: scenario has team_maturity below staff_plus
Cassandra has the highest operational complexity of common datastores: consider managed options (Astra DB, Keyspaces) or simpler alternatives
When: scenario requires ad-hoc queries or analytics
Cassandra cannot efficiently query non-partition-key dimensions: pair with Elasticsearch or ClickHouse for analytics
When: scenario has time_series or iot_telemetry workload
Design partition keys with time-bucketing (e.g., date prefix) to prevent wide partitions as data grows
Comparison Factors
write scalability
Very high: linear write scaling with no single-primary bottleneck
operational complexity
Very high: repair, compaction, schema management, and tuning require dedicated expertise
query flexibility
Very low: partition key access only; no ad-hoc queries or joins
availability
Very high: no single point of failure; always-on design
Managed Cloud Options
Enables Patterns
Basis
Widely documented at scale; operational characteristics confirmed in production engineering posts and academic papers
Sources & Claims
Cassandra writes are first appended to an on-disk commit log for crash recovery and written to an in-memory memtable, not directly to a disk-resident SSTable
pendingofficial documentation · Apache Cassandra documentation on the write path (commit log and memtables)
storage-engine-internals-spine batch 5
A Cassandra memtable is flushed to disk as an immutable SSTable when it reaches a configured size threshold or flush interval
pendingofficial documentation · Apache Cassandra documentation on memtables and SSTables
storage-engine-internals-spine batch 5
Cassandra maintains a per-SSTable Bloom filter that can probabilistically prove a partition key is absent from that SSTable, allowing the SSTable to be skipped during a read without a disk I/O
pendingofficial documentation · Apache Cassandra documentation on Bloom filters
storage-engine-internals-spine batch 5
SizeTieredCompactionStrategy is Cassandra's default compaction strategy and is write-optimized with burstier compaction I/O, while LeveledCompactionStrategy organizes SSTables into fixed-size levels for steadier read latency at the cost of more total bytes rewritten by compaction
pendingofficial documentation · Apache Cassandra documentation on compaction strategies (SizeTieredCompactionStrategy, LeveledCompactionStrategy)
storage-engine-internals-spine batch 5
Cassandra tombstones must persist until gc_grace_seconds has elapsed across all replicas before being purged by compaction, to prevent a deleted row from resurrecting via a replica that missed the delete
pendingofficial documentation · Apache Cassandra documentation on tombstones and gc_grace_seconds
storage-engine-internals-spine batch 5
Learning Modules
CAP Theorem and PACELC
Why distributed systems cannot simultaneously provide consistency, availability, and partition tolerance: and how PACELC extends this to the latency-consistency tradeoff that applies even when the network is healthy.
Consistency Models in Distributed Systems
The consistency spectrum from linearizability to eventual consistencywhat each model guarantees, which real systems implement each model, and how to design application code for the consistency level your infrastructure provides.
Eventual Consistency
How eventual consistency models propagate updates across nodes, how convergence windows create read anomalies, how conflict resolution works, and when strong consistency is required instead.
Partition Hotspots
How partition key design determines load distribution, how sequential keys create hotspot partitions, why hotspots cause cascading failures, and how to design partition keys that distribute load uniformly.
Write Amplification
How a single application write triggers multiple physical I/O operations across WAL, heap pages, and indexes, why this limits write throughput, and how LSM trees trade read amplification for lower write amplification.
Related Architecture Knowledge
Outbound: this entity affects
Cassandra's distributed architecture relies on consistent hashing for node-to-token assignment and data replication, enabling linear write scalability as nodes are added without rebalancing all existing data.
Tradeoffs
- ·Consistent hashing in Cassandra means partition key must be chosen for distribution, not range queries
- ·RF=3 across 3 AZs is recommended: RF determines the quorum read/write requirements
- ·Token imbalance (despite vnodes) can occur if node sizes are heterogeneous: use DataStax OpsCenter for monitoring
Cassandra's LSM-tree storage engine accumulates SSTables that must be checked during reads; insufficient compaction allows SSTable depth to grow, increasing the I/O required per read.
Full relationship →Cassandra uses a consistent hash ring (via Murmur3 partitioner by default) to distribute partition keys across nodes. Virtual nodes (vnodes) improve distribution uniformity and enable automatic rebalancing when nodes join or leave.
Tradeoffs
- ·Murmur3 partitioner prevents range queries across partition keys: range queries require a secondary index
- ·Consistent hashing distributes data but does not prevent hot partitions if access is skewed
- ·Vnodes increase repair complexity: more token ranges to repair per node compared to single-token assignment
Used In Architecture Scenarios
AI / RAG Application
A low-latency feature serving platform for ML model inference, providing both batch (offline) and real-time (online) feature access with strict training-serving consistency. Redis serves the hot feature cache with p99 latency targets below 5ms for online inference requests; PostgreSQL provides point-in-time feature lookups for offline training jobs with temporal consistency guarantees; Cassandra stores high-cardinality feature entities at write scale beyond PostgreSQL's single-primary ceiling; Kafka streams feature computation events from online feature pipelines to update the cache; Qdrant stores vector features for embedding-based model inputs and similarity lookups; ClickHouse serves feature analytics and drift monitoring across training dataset populations. Feature versioning is first-class: every feature value is tagged with a pipeline_version and computed_at timestamp to support model reproducibility and training-serving skew diagnosis.
Event-Driven System
A video and audio streaming architecture where content ingestion triggers an async multi-variant transcoding pipeline, CDN delivery handles 95%+ of playback traffic, and Cassandra absorbs the write volume of per-user viewing history. Kafka decouples upload events from transcoding workers; MinIO stores raw and encoded assets; Redis maintains playback session state and view counters. The architecture must handle upload spikes without blocking delivery, and cache cold starts without cascading database load.