Cassandra#

Wide-column Eventually consistent Massively scalable

What it is#

Apache Cassandra is a distributed wide-column database designed from the ground up for horizontal scale across many nodes, including across data centers, with no single point of failure. There is no primary node, every node is equal (a "masterless" architecture).

How it works under the hood#

Data is partitioned across the cluster by a partition key, using consistent hashing so adding or removing nodes only reshuffles a fraction of the data. Every piece of data is replicated to multiple nodes (controlled by a replication factor), and reads and writes can tolerate some nodes being down entirely, controlled by a tunable consistency level per query.

Setting it up#

Docker

docker run --name cassandra -p 9042:9042 -d cassandra:5

Local install

tar -xzf apache-cassandra-5.0-bin.tar.gz
cd apache-cassandra-5.0
bin/cassandra -f

Your first queries (CQL)#

CREATE KEYSPACE app WITH replication = {
  'class': 'SimpleStrategy', 'replication_factor': 3
};

CREATE TABLE app.events (
  device_id text,
  event_time timestamp,
  payload text,
  PRIMARY KEY (device_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

INSERT INTO app.events (device_id, event_time, payload)
VALUES ('sensor-1', toTimestamp(now()), '{"temp": 21.5}');

CQL looks like SQL but isn't. You can't join tables, and you generally can't query by anything other than the partition key without a secondary index or a separate table designed for that access pattern.

Modeling data query-first#

Note

In a relational database you model entities, then write queries against them. In Cassandra you design the table around the specific query it needs to serve, and you often duplicate data across multiple tables to support different access patterns. This is the single biggest mental shift for people coming from SQL.

Tunable consistency#

Consistency level	Meaning
`ONE`	Only one replica needs to respond, the fastest option and the weakest guarantee
`QUORUM`	A majority of replicas must respond, the common middle ground
`ALL`	Every replica must respond, the strongest guarantee and the least available under failure

CONSISTENCY QUORUM;
SELECT * FROM app.events WHERE device_id = 'sensor-1';

In production#

nodetool status
nodetool tpstats

Warning

A poorly chosen partition key creates a "hot partition", one node absorbing far more traffic than the rest of the cluster, which defeats the entire point of a distributed design. This is the Cassandra equivalent of a MongoDB hot shard.

Repair (nodetool repair) needs to run regularly to reconcile data across replicas that missed writes during downtime, skipping it for too long risks permanently inconsistent data.

Pros and cons#

Pros

Linear horizontal write scalability across many nodes
No single point of failure, survives node and even data center loss
Tunable consistency per query
Proven at genuinely massive scale (originated at Facebook, used at Netflix, Apple)

Cons

No joins, no ad hoc queries outside your modeled access patterns
Query-first modeling is a real learning curve
Operational complexity (repair, compaction, tombstones) is significant
Overkill for anything that fits on one strong Postgres instance

When to reach for it#

Good fits: time-series and event data at huge scale, write-heavy workloads (IoT telemetry, activity logs), applications needing multi-data center replication with no single point of failure, and access patterns that are well understood in advance.

When it's not the right fit#

Applications needing flexible, ad hoc querying
Small to medium datasets that don't need this level of horizontal scale
Teams without the operational capacity to run a distributed database

multi-region-considerations and consistency-tradeoffs-at-scale cover the distributed-systems concepts Cassandra leans on most heavily.