Cassandra
Wide-column, partition keys, eventual consistency at scale.
Theory
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 DCExamples
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;
INSERT INTO events (bucket, ts, data) VALUES (?, ?, ?) USING QUORUM;
Key Concepts
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
Practical Exercises
Design inbox table by user_id with clustering by message time.
Explain celebrity user problem and mitigation (salting, separate bucket).
Sketch RF=3 NTS across us-east and eu-west.