Cassandra

DynamoDB is a managed, opaque implementation of the ideas in Amazon's Dynamo paper. Cassandra — which originated at Facebook, combining that same distribution model with Google's Bigtable-style wide-column data model — is the open-source, self-operated system built on the same lineage, and it comes up whenever a design needs to stay writable and available even while parts of the network are unreachable.

A masterless ring

Every Cassandra node is a peer — there's no leader node coordinating writes, unlike Kafka's per-partition leader in Message Queues. Nodes are arranged on a hash ring via consistent hashing, and each key is owned (and, for replication, also held by the next N-1 nodes clockwise) based purely on where its hash lands — the exact mechanism that lesson describes in the abstract, with Cassandra as one of its most direct real implementations.

Any node can act as the coordinator for any request, forwarding it to whichever nodes actually own that key's replicas — which is also why losing a node doesn't stop the cluster from accepting writes for the keys it held; another replica just answers instead.

Tunable consistency: N, R, and W

Three numbers govern every read and write: N, the replication factor (how many nodes hold a copy); W, how many replicas must acknowledge a write before it's considered successful; and R, how many replicas a read must query before returning a result. If R + W > N, every read is guaranteed to overlap with the most recent write, giving strong consistency at the cost of waiting on more nodes per operation. If R + W <= N, reads and writes are faster and more available, but a read can return a stale value if it happens to miss every replica that has the latest write — the same strong-vs-eventual trade-off named generally in Consistency and CAP, here exposed as a literal, tunable per-query setting rather than a single system-wide choice.

No coordinator means state has to spread itself

With no central node tracking cluster membership, nodes tell each other what they know via a gossip protocol — periodically exchanging state with a few random peers, so information about a new or failed node eventually reaches everyone without any single node being a bottleneck or a single point of failure. Two related mechanisms keep replicas from drifting apart under this model: read repair, where a read that notices replicas disagree pushes the newest value back out to the stale ones, and hinted handoff, where a write meant for a temporarily unreachable node is held by another node and delivered once it comes back — both quietly closing the gap that eventual consistency otherwise leaves open.