Cassandra

Cassandra is a distributed wide-column database designed for one thing above all: taking a very high volume of writes across many machines, with no single master. When your write rate or dataset outgrows what one relational primary can handle — time-series data, event logs, message history, feeds at scale — Cassandra is a common answer.

How it scales so well

Cassandra is masterless: every node is equal, data is spread across them with consistent hashing, and you can add nodes to grow linearly. There's no single primary to bottleneck writes, and it replicates each row to several nodes for fault tolerance. The result is a store that absorbs writes at enormous scale and survives node failures without downtime.

The model: design around the query

This is the mental shift from SQL. In Cassandra you do not model entities and join them — joins don't exist. You design one table per query, with data laid out so each query reads one partition:

• The partition key decides which node holds the data, and is the thing every query filters by. Pick it so your common query hits exactly one partition.
• Clustering columns order rows within a partition (e.g. messages by timestamp), so "latest N messages in this chat" is a single, fast, pre-sorted read.

messages_by_chat (
  chat_id      ← partition key (all a chat's messages on one node, ordered)
  sent_at      ← clustering column (DESC)
  message_id, sender, body
)

If you also need "messages by user," you create a second table keyed that way and write to both. Denormalization and duplication are the norm, not a smell.

Tunable consistency

Cassandra lets you choose consistency per query along the CAP spectrum. You pick how many replicas must acknowledge a write (or answer a read): ONE is fast but can be stale; QUORUM (a majority) gives strong-ish consistency at more latency; and QUORUM reads + QUORUM writes together guarantee you read the latest write. You dial correctness vs. speed for each operation.

What to watch

• No joins, no ad-hoc queries. You can only query by the keys you designed for. A new access pattern means a new table and a backfill.
• Bad partition keys hurt. A key that creates one giant partition (e.g. a global "all events" partition) or a hotspot (sharding by day) undoes the scaling.
• Not for strong transactions. It's built for scale and availability, not multi-row ACID. Keep money/transactional data in a relational store.

What to say in an interview

Reach for it when writes/volume exceed one primary and queries are known up front:

"Chat message volume outgrows a single Postgres primary, so I'd store messages in Cassandra, keyed by chat_id with sent_at as a clustering column — a chat's history lives on one node, pre-sorted, so loading a conversation is one fast read. I'd use QUORUM where I need freshness. The transactional user/billing data stays in Postgres."

Next up: DynamoDB — the managed key-value/document store with the same single-table mindset.