Interactive guide · 7 chapters · ~14 min read
Cassandra Engineering Insights
The design decisions, trade-offs, and comparisons that come up most often when reasoning about — or defending the choice of — Cassandra.
Mangesh MandlikLast updated:
01 · Design decisions
Why Cassandra Uses a Peer-to-Peer Architecture
A master/replica architecture has a structural weak point: the master. Cassandra's designers chose to eliminate that weak point entirely, at the cost of a simpler consistency model.
In a master/replica system, all writes (and often reads) funnel through one node. If that node fails, the system needs an election or failover process — during which it is at best degraded, at worst unavailable. Cassandra's peer-to-peer design means every node can serve any request, so there's no failover pause and no special node whose loss is more dangerous than any other's.
02 · Trade-offs
CAP Theorem
The CAP theorem says a distributed system can only guarantee two of Consistency, Availability, and Partition tolerance at once — and partition tolerance isn't really optional.
Networks fail. Partition tolerance (P) is a requirement, not a choice, for any real distributed system — so the actual trade-off in practice is between Consistency (C) and Availability (A) during a partition. Cassandra is designed for availability with tunable consistency: depending on the replication factor and the consistency level each operation requests, it can keep serving reads and writes on both sides of a partition, and reconciles divergence afterward via read repair and anti-entropy repair.
03 · Consistency model
Eventual Consistency
Eventual consistency means: if no new writes occur, all replicas will eventually converge to the same value — but there's no bound on exactly when.
Cassandra achieves eventual consistency via a combination of mechanisms: hinted handoff (short-term), read repair (opportunistic, triggered by reads), and anti-entropy repair (scheduled, comprehensive). None of these guarantee immediate consistency, but together they ensure replicas converge over time.
04 · Comparisons
Cassandra vs PostgreSQL
PostgreSQL is a strongly consistent, ACID-transactional relational database built around a single writable primary — almost the opposite design philosophy from Cassandra.
Consistency & transactions
PostgreSQL offers full ACID transactions and joins out of the box. Cassandra offers tunable consistency and lightweight transactions (Paxos-based in 4.x and 5.0) only for specific compare-and-set operations — it is not a general transactional database.
Scaling model
PostgreSQL scales vertically (bigger machine) or via read replicas / manual sharding. Cassandra scales horizontally by design — add nodes, and both storage and throughput grow close to linearly in practice, provided the partition key spreads load evenly.
05 · Comparisons
Cassandra vs MongoDB
Both are NoSQL databases built for horizontal scale, but they solve very different data-shape and consistency problems.
Data model
MongoDB stores flexible, nested JSON-like documents — great for evolving object shapes. Cassandra stores wide-column rows optimized for very high write throughput and query-first denormalization, not document nesting.
Architecture
MongoDB (in sharded mode) still has primary/secondary replica sets per shard, plus config servers and query routers. Cassandra is fully peer-to-peer with no special node roles at all.
06 · Comparisons
Cassandra vs DynamoDB
DynamoDB and Cassandra both trace their design lineage to Amazon's Dynamo paper, but they are different systems: DynamoDB is a fully managed service, while Cassandra is open-source software you operate yourself (or pay a vendor to operate).
Operational model
DynamoDB is serverless and fully managed by AWS — no nodes to provision, patch, or repair. Cassandra requires you (or a managed provider like DataStax/AWS Keyspaces) to run and tune the cluster: compaction, repair, capacity planning are all your responsibility.
Portability & lock-in
Cassandra is open-source and portable across any cloud or on-prem datacenter. DynamoDB is AWS-only, trading portability for zero operational overhead.
07 · Pitfalls
Common Mistakes & FAQs
Most Cassandra production incidents trace back to a small set of recurring modeling and operational mistakes.
Modeling like a relational database
Trying to normalize tables and join at query time — Cassandra has no joins, so this forces expensive application-side joins or, worse, full table scans.
Ignoring partition size
Letting partitions grow unbounded (e.g. keying only by user ID for an infinite event log) eventually degrades reads, compaction, and repair.
Treating it as a queue
High-churn insert-then-delete patterns generate excessive tombstones, which slow down reads that must scan past them.
Key takeaways
- 01Cassandra's peer-to-peer architecture trades a simpler consistency model for eliminating any single point of failure.
- 02CAP theorem in practice: partition tolerance isn't optional, so the real choice is Consistency vs Availability during a partition — Cassandra defaults to Availability.
- 03Eventual consistency is achieved via hinted handoff, read repair, and anti-entropy repair working together, not a single mechanism.
- 04Cassandra trades PostgreSQL's ACID transactions and joins for horizontal write scalability and tunable consistency.
- 05Compared to MongoDB and DynamoDB, Cassandra is uniquely fully masterless and self-operated (unless using a managed offering).