Loading...
Loading...
Persistent data storage with ACID guarantees
Database Sharding Architecture
You already know from the relational-tables module how fixed schemas plus joins answer flexible questions on one machine, and from the latency module why disk seeks and lock queues cap what that machine sustains. Sooner or later the data stops fitting, or the writes stop fitting through one machine. Two escapes exist, and they solve different halves: split it up (sharding, dividing rows across machines so each holds a slice) so no box holds everything, and copy it (replication, keeping extra copies of the same rows on other machines) so no box is irreplaceable.
Think of a phone book too big for one binder, the one comparison we will use here: split the alphabet across binders so no binder bursts, and photocopy the popular pages so losing one binder never loses names. In the lab above, grow writes until one machine saturates, then split into shards and kill one copy, and watch capacity rise while availability holds, because splitting buys room and copying buys survival.
A single server has three ceilings: disk space, requests per second, and the fact that it can die. We rejected buying a bigger box as the permanent answer because QPS means queries per second, the request rate it sustains, and the split math never bends. Do the split math: 10 terabytes at 1 terabyte per box needs at least 10 shards before copies, and 100,000 QPS at 10,000 per box needs at least 10 serving machines before replicas. One box cannot outgrow arithmetic.
Keep several copies of the same rows on different servers. One primary (the leader that accepts writes) streams changes to replicas (followers that serve reads). Reads scale because followers share them, and survival improves because a follower steps up when the leader dies. The price is lag: a follower can serve yesterday's row for the milliseconds before the new write arrives, a state called eventual consistency, meaning copies agree if writes stop but may disagree briefly.
In the lab, kill the primary under read load and watch writes pause while reads continue, because followers can serve old truth but cannot mint new truth until one is promoted.
Split one table into disjoint slices called shards, where disjoint means no row lives in two shards. A shard key (the column whose value picks the slice, like user id) decides placement. Each shard is an independent database holding its slice, so capacity and write throughput grow with shard count. The edge case is a bad key: sharding by country piles half your users onto one shard, a hotspot, meaning one machine burns while others idle.
Splitting 3 shards into 6 reassigns about half the rows. Consistent hashing or pre-made virtual slices keep the move near the minimum instead of reshuffling everything.
The CAP theorem says a distributed store facing a network partition (a break that stops machines from reaching each other) can keep every reply identical or keep every request answered, not both. Consistency means same data everywhere. Availability means always answering. Partition tolerance means surviving the break. Since breaks happen, the real choice is between refusing during splits or answering with possibly old data.
SQL stores enforce fixed schemas with ACID transactions (all-or-nothing multi-row updates that stay correct under crashes). NoSQL stores trade some of that strictness for built-in sharding and looser BASE behavior (basically available with soft, converging state). Pick strict when money moves, pick flexible when the access pattern is one key, one read, at enormous scale.
Large social stores shard the graph by user id so one person's neighborhood lives together, then copy each shard across regions. A friend lookup stays local while a region outage still leaves a copy answering.
Managed key-value services split by key hash automatically and copy across zones. You get room by adding keys and sleep through zone failures, at the price of thinking carefully about hot keys and lag.
Split it so no box holds everything, copy it so no box is irreplaceable. Sharding buys room to grow, replication buys sleep at night. For the dataset you care about most right now, which limit would hit first, disk room or write throughput, and which half of the answer would you build first?
Try this in the playground
Open a template and build it yourself — then take a quiz.