Index/Cassandra

SponsorGitHub
Key technologyWide-column store4 min

Cassandra

Masterless, write-optimised storage that scales linearly — as long as every query is known in advance.

At a glance

Model
Partition key + clustering columns; no joins, no ad-hoc filters
Topology
Masterless ring, vnodes, gossip — nothing to fail over
Writes
LSM tree: commit log + memtable, acked before any disk seek
Consistency
Per query: R + W > N gives you a fresh read
Conflicts
Last-write-wins on timestamps; concurrent updates drop one
Geography
Multi-datacenter replication with a local quorum

Key concepts and capabilities

The short listwhat it gives you
The data model is the query plan — the partition key picks the node, clustering columns set the order inside it
Duplicate, don't index — a second table per query, written at the same time, because writes are the cheap part
LSM writes — commit log plus memtable, acked before any disk seek; SSTables are immutable and compacted later
R + W > N — the dial per query; QUORUM both ways is the usual pick, ONE buys latency and gives up freshness
Tombstones — a delete is a marker, so heavy deletion makes range reads slower; this is why it is a bad queue
Compaction strategy — size-tiered for write-heavy, leveled for predictable reads, time-window for TTL'd time series
Repair — hinted handoff, read repair and scheduled anti-entropy keep replicas honest
Last-write-wins — concurrent updates to a cell silently drop one, and clock skew picks the winner
Bucket unbounded partitions — add a time component to the partition key before one channel grows forever

Use cases

Chat messages and feeds, keyed for the query

The canonical shape. channel_id picks the node, day_bucket stops one busy channel growing an unbounded partition, and created_at DESC makes "the last 50 messages" one contiguous read. A second query means a second table holding the same rows, written at the same time.

primary or partition keysort key, ↓ newest firstforeign key → referenced columnHover a table or column to trace its keys

Absorbing a firehose of writes

Every node accepts every request, and a write is durable after a sequential append plus a memory write — no read-before-write and no random disk IO. That is why the answer to "two million writes a second, append-only" is this shape rather than a bigger primary.

DatabaseFocusClick a node for details

Choosing freshness per query

Consistency is a dial you set per statement, not a property of the cluster. Work the arithmetic out loud: with N=3, QUORUM writes and QUORUM reads overlap on at least one replica, so a read sees the latest acknowledged write and one node can be down. ONE is faster and may be stale — fine for a view counter, not for a balance.

FocusClick a node for details

Writing in two regions without a leader

Replicas are placed per datacenter, and each side commits on a local quorum, so a write in Frankfurt does not wait for Virginia. Cross-region replication is asynchronous, and conflicts resolve last-write-wins — which is exactly why this suits feeds and messages, and not balances.

DatabaseFocusClick a node for details