Database Systems · Guide

Cassandra

Wide-column, partition keys, eventual consistency at scale.

— min read Database Systems

Theory

Cassandra optimizes for write-heavy, multi-datacenter availability — design around partition keys first, queries second.

Apache Cassandra is a distributed wide-column store (partition key + clustering columns). Data is partitioned with consistent hashing across nodes.

Tunable consistency per query: ONE, QUORUM, ALL — trade latency vs correctness. Lightweight transactions (LWT) use Paxos for compare-and-set.

Replication Factor (RF) copies data across nodes; NetworkTopologyStrategy places replicas per datacenter for local reads.

Writes go to commit log then memtable; SSTables flush to disk with periodic compaction (size-tiered, leveled).

CQL resembles SQL but multi-table JOINs are absent — model denormalized tables per query pattern (one table per query).

Netflix and Apple use Cassandra for time-series-ish, high-ingest workloads where Postgres would struggle to scale writes horizontally.

Operations: nodetool repair, rebuild, decommission; watch compaction lag, pending hints, and p99 read latency.

Architecture Diagram

  Client (CQL)
      |
  Coordinator node
      |
  +---+---+---+
  v   v   v   v
  N1  N2  N3  N4   (ring)
  RF=3 replicas per DC

Examples

cql
CREATE TABLE orders_by_user (
  user_id uuid,
  order_id timeuuid,
  total decimal,
  PRIMARY KEY (user_id, order_id)
) WITH CLUSTERING ORDER BY (order_id DESC);

SELECT * FROM orders_by_user WHERE user_id = ? LIMIT 20;
cql consistency
INSERT INTO events (bucket, ts, data) VALUES (?, ?, ?) USING QUORUM;

Key Concepts

Partition keyHash bucket for rows
Clustering columnsSort order within partition
Hinted handoffTemporary write buffer when replica down

Interview Questions

What is a partition key?

Determines which node owns the row; all rows with same partition key live together — hot partitions limit scale.

QUORUM meaning?

Majority of replicas (typically (RF/2)+1) must respond — balances consistency and availability.

When NOT to use Cassandra?

Heavy ad-hoc analytics, multi-table transactions, or workloads needing rich relational joins.

What causes hot partitions?

Skewed partition keys (celebrity user, single time bucket) — mitigate with salting, separate buckets, or pre-sharding keys.

Lightweight transactions (LWT)?

Paxos-based conditional writes (IF NOT EXISTS) — higher latency; use sparingly, not as general transactions.

Repair and nodetool?

Periodic repair syncs replicas; monitor pending hints and compaction backlog after node failures.

Multi-datacenter replication?

NetworkTopologyStrategy places replicas per DC; tune consistency (LOCAL_QUORUM) for local reads in each region.

Best Practices

  • Version-control all Cassandra configuration and review changes like application code.
  • Automate validation (lint, policy checks) in CI before production apply.
  • Document ownership, on-call runbooks, and rollback for every production change.
  • Use least privilege for credentials and rotate secrets regularly.
  • Measure before/after: error rate, deploy time, cost, or toil hours saved.

Common Mistakes

  • Adopting Cassandra without a written problem statement or success metric.
  • Skipping staging that mirrors production networking and data volume.
  • No rollback path — forward-only changes during incidents.
  • Alert noise without actionable runbooks — on-call ignores pages.

Cheat Sheet

RFReplica count
CLConsistency level
SSTableOn-disk immutable file

Practical Exercises

Data model

Design inbox table by user_id with clustering by message time.

Hot partition

Explain celebrity user problem and mitigation (salting, separate bucket).

Multi-DC

Sketch RF=3 NTS across us-east and eu-west.