Loading...
Loading...
Distributed NoSQL database designed to handle massive amounts of data with high availability.
A distributed, masterless NoSQL database designed to handle massive amounts of data across multiple servers with zero single points of failure.
Cassandra has no 'Master' node. All nodes are peers. A client connects to ANY node (acting as the Coordinator). The Coordinator hashes the partition key to mathematically determine exactly which node owns the data.
What happens if the Coordinator node goes down before the client can connect?
You already know from the replication module how a single primary streams writes to followers and becomes the bottleneck plus the failover wait, and from the sharding module how a shard key decides which machine owns each row. Picture millions of people logging in, pausing, and saving shows at once. If your database relies on a single master server (one machine that handles every write while the rest only copy it), you have a bottleneck and a single point of failure, meaning one dead machine stops all writes. Cassandra (a distributed database where every machine is equal and any machine accepts reads or writes) removes that machine entirely.
Think of a traffic circle with no stoplight, the one comparison we will use here: every entrance is equal, cars keep flowing from any direction, and losing one entrance never stops the circle. In the lab above, kill one node mid-write and watch traffic keep flowing, because no coordinator is special and the ring simply routes around the missing piece.
Cassandra looks like a relational database (tables with rows and a query language called CQL that reads like SQL), but you model data backwards: start from the exact questions you will ask, then shape tables so each question reads one tight group of rows.
| Familiar idea | Cassandra name | What it actually controls |
|---|---|---|
| Database | Keyspace | A namespace that sets how many copies of each row exist and where they live. |
| Table | Table | You design one table per question, duplicating data freely so reads stay local. |
| Primary Key | Partition Key | The hashed part that decides which machines own the row. |
| ORDER BY | Clustering Key | The part that decides the sorted order on disk inside one machine. |
The naive relational habit is one clean users table plus joins at read time. We rejected that habit here because rows for one question scatter across machines and joins become network chases. The Cassandra habit duplicates user details into the orders-by-user table and the orders-by-city table, paying extra storage once to make every read a single local fetch.
With no master tracking locations, Cassandra uses consistent hashing (a scheme where both machines and keys map onto a shared ring, so each key belongs to the next machine clockwise). The client hashes the partition key into a number, walks clockwise, and talks directly to the owner. Work the toy: four machines own ranges 0 to 24, 25 to 49, 50 to 99 style slices, so user_123 hashing to 78 belongs to the machine owning 50 to 100.
The payoff: no lookup service sits on the path, so adding machines only reassigns the slices next to the newcomer. In the lab, add a fifth node and count how few keys move, then compare against naive key-modulo-machine-count where nearly everything would move.
Cassandra never rewrites files in place. It appends to a crash log, answers from memory, and later flushes sorted files in bulk, which turns random writes into sequential ones. Sequential disk appends run tens of times faster than random seeks, which is the one layer deeper that explains the famous write speed.
Your client reaches any node. That node becomes the coordinator (the temporary forwarder for this one request) and sends the write to the machines that own the key.
Each owner appends the write to a commit log (an append-only file that replays after a crash) for durability, meaning survival across restarts.
The write lands in a memtable (a sorted structure in RAM). Once enough owners confirm, the coordinator replies success without waiting for disk sorting.
When memory fills, it flushes to an SSTable (an immutable, meaning never edited in place, sorted file on disk). Later a background merge compacts overlapping files.
The edge case is a write storm that fills memory faster than flushing drains it. Then memtables queue, latency climbs, and the coordinator starts shedding load. In the lab, push writes past the flush rate and watch that queue grow, because memory is fast only while it drains.
Speed against freshness, chosen per request.
The replication factor (how many machines hold each row, say 3) sets the copies. The consistency level (how many copies must answer before the coordinator replies) sets the promise. ONE waits for a single copy, so it is fast and can serve a stale copy that has not yet received the newest write. QUORUM waits for a majority, here 2 of 3, so overlapping majorities guarantee the reader sees the latest acknowledged write, at the cost of waiting for the slower of the two. The CAP theorem (the rule that during a network split you must choose between always answering and always agreeing) is this dial made visible.
Coordinator waits for 1 of 3 copies. A Friday-night dashboard survives two slow machines, but two readers can briefly disagree.
Waits for 2 of 3. Any two majorities overlap on at least one machine, so the fresh write is always found. Slightly slower, far more trustworthy.
In the lab, flip one read from ONE to QUORUM while a node lags and watch stale answers vanish as latency ticks up. That is the trade, priced in milliseconds.
No masters, tunable promises, writes that never wait. Cassandra bets the whole design on one insight: at planetary scale, coordination is the bottleneck, so it coordinates as little as physics allows. If you can dial every read between fast-and-possibly-stale and slow-and-current, where would you set that dial for a like counter versus a password change?
Try this in the playground
Open a template and build it yourself — then take a quiz.