Technology · Wide-column database
Cassandra
A leaderless, wide-column database built for huge write volumes across many nodes and regions. Query-first data modeling, tunable consistency, and its sharp edges.
10 min read
Cassandra (and ScyllaDB, a compatible rewrite) spreads data across a ring of equal nodes with no leader. Writes are cheap appends, nodes can be added for nearly linear scale, and clusters can span regions. In exchange you give up joins, flexible queries and multi-row transactions.
When to reach for it
- Very high write throughput: events, messages, time series, activity logs.
- Access patterns are known in advance and look up by key, usually reading a range within one partition.
- You need multi-region, always-writable storage and can accept eventual consistency.
If you need joins, ad hoc queries or transactions across entities, prefer Postgres or a distributed SQL database.
Data model
A table has a partition key, which decides which nodes store the row, and clustering columns, which sort rows inside the partition.
CREATE TABLE messages (
conversation_id uuid,
sent_at timeuuid,
sender_id uuid,
body text,
PRIMARY KEY ((conversation_id), sent_at)
) WITH CLUSTERING ORDER BY (sent_at DESC);"Latest 50 messages in a conversation" reads one partition, already sorted. Model one table per query, and denormalize: writing the same data to two tables is normal.
How it works
- Partition keys are hashed onto a token ring with virtual nodes; each key is stored on N replicas (typically 3), per data center.
- Any node can coordinate a request. Writes go to the commit log and an in-memory memtable, later flushed to immutable SSTables: an LSM tree.
- Compaction merges SSTables in the background, dropping overwritten values and expired tombstones.
- Consistency is chosen per request: ONE, QUORUM, LOCAL_QUORUM, ALL. QUORUM writes plus QUORUM reads overlap, so reads see the latest acknowledged write.
- Hinted handoff, read repair and scheduled anti-entropy repair bring replicas back in sync.
- Writes per nodeScyllaDB goes higher
- ~10,000–50,000 per second
- Read latencyfor single-partition reads
- single-digit ms at p99
- Recommended partition sizeand under ~100,000 rows
- under ~100 MB
- Cluster size
- dozens to thousands of nodes
Tunable consistency
ONE
- Lowest latency
- Most available
- Reads may be stale
Pick it when: Metrics, logs, likes.
LOCAL_QUORUM
- Strong within a region
- No cross-region wait
- Regions converge asynchronously
Pick it when: The common default for multi-region apps.
QUORUM / ALL
- Strongest reads
- Cross-region latency
- ALL fails if any replica is down
Pick it when: Rarely; small critical reads.
Where it bites
- Deletes create tombstones. Queue-like patterns (insert, then delete) make reads scan piles of tombstones and slow to a crawl.
- No joins, limited secondary indexes, and lightweight transactions (Paxos-based compare-and-set) are slow; use them sparingly.
- Last-write-wins by timestamp resolves conflicts, so clock skew can drop updates.
Try it
Chat Service HLD
Store and serve chat history at scale.