Apache Cassandra Overview

Cassandra is a masterless, wide-column distributed database. Every node is equal, any node can serve any request, and data is partitioned across the cluster by a hash of the partition key.

Architecture

• Ring. Nodes form a token ring; each owns ranges of the token space. See Cassandra Architecture.
• No coordinator role. The node a client contacts acts as coordinator for that request and forwards to the replicas.
• LSM storage. Writes go to a commit log and an in-memory memtable, which is flushed to immutable SSTables. Background compaction merges them. This makes writes fast and consistently cheap.
• Tunable consistency. Every read and write specifies how many replicas must respond. See Consistency Levels.
• Gossip. Nodes exchange state peer to peer; there is no configuration server.

Best use cases

• Very high write throughput that exceeds a single node — time series, event capture, telemetry, messaging.
• Workloads keyed by an entity: "all events for this device", "all messages in this conversation".
• Multi-datacenter deployments where each region serves local traffic with local latency.
• Systems that must keep accepting writes while nodes are down.

When not to use it

• When queries are not known in advance. There is no query planner and no joins; tables are designed per query. An unanticipated access pattern means a new table and a backfill.
• For read-modify-write workloads. There is no cheap compare-and-set; lightweight transactions use Paxos and cost several times a normal write.
• For small datasets. A three-node cluster to hold 50 GB is operational overhead with no benefit.
• For analytics. Aggregations across partitions are expensive; export to a column store instead.

Data model

CREATE KEYSPACE shop
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'eu-central': 3,
  'us-east': 3
};
 
CREATE TABLE shop.events_by_user (
    user_id     uuid,
    bucket      date,          -- partition bucketing keeps partitions bounded
    event_time  timestamp,
    event_id    timeuuid,
    event_type  text,
    payload     text,
    PRIMARY KEY ((user_id, bucket), event_time, event_id)
) WITH CLUSTERING ORDER BY (event_time DESC, event_id DESC);

The primary key has two parts: the partition key (user_id, bucket) decides which node stores the row, and the clustering columns event_time, event_id decide the sort order within the partition. See Data Modeling.

Consistency and transactions

No multi-partition transactions. A write to a single partition is atomic and isolated. Lightweight transactions (IF NOT EXISTS, IF column = value) provide linearizable compare-and-set within one partition using Paxos, at a significant latency cost.

Consistency is per query, which is the point: LOCAL_QUORUM for the operations that need it, ONE for the ones that do not.

Scaling model

Adding nodes adds capacity nearly linearly, because writes distribute by partition key hash and no node coordinates the others. Cassandra's scaling story is genuinely simple — its data modelling is where the difficulty lives.

Common mistakes