Slice and Grow: A Plain Guide to Splitting Databases

Two friends launch a tiny social app; call it Chirp. A few hundred curious people join on day one, and one app server plus one database box handles everything. Tap post and the note lands instantly; open a profile in a blink. A corner shop with one till and a short queue. Nobody talks about scale yet; everyone chases signups. I like this picture because it shows the trouble of scale by first showing its absence.

Then the headcount climbs from hundreds to thousands and beyond. Split the load into two jobs. One is reads: opening a profile, listing posts. The other is writes: fresh posts, new follows. When both pile onto one box, the queue stretches. First reflex: buy a bigger box with a stronger processor and roomier memory. That road ends at a wall. One day no bigger box exists, or the bill stings. The sharding question is born exactly at that wall.

Sharding means slicing tables and seating each slice on its own server. The users table splits four ways, every slice on separate hardware. Up front stands a traffic officer: the routing layer, which knows which question goes where. Picture one corner shop swapped for four branches plus a front desk sending each visitor to the right branch. Simple to say, delicate to pull off.

The first delicate part is the shard key: the column that scatters rows across slices. The Chirp team picks the user id. What if the key changes later? Say the team moves to country-based splits. Every row on every slice needs a review, every owner needs a country lookup, every row needs a haul to its new home. A giant move. So the pick deserves sober thought upfront. The MongoDB docs sound the same warning: weigh value variety, value frequency, and whether the key keeps growing.

A good key has habits. One: loads of distinct values. Splitting by country gives some two hundred values for sixty-four slices; slices holding crowded regions sweat while quiet ones idle. User ids offer millions of values for as many slices as wanted. Two: newcomers land evenly. Splitting by signup year stuffs this year's slice while older ones gather dust. Sequential ids walk zero, one, two, three and balance themselves.

The first layout path is hashing. Push the id through a hash function, divide by the slice count, keep the remainder. Leo lands on slice zero. The beauty: id plus slice count suffice, so every server figures alone with no chatter. Like drawing lots for laundry baskets, where everyone knows the rule by heart. Teams with few range questions love this path.

The second path is ranges. Each slice owns a span of values. A banking app keeps March records together on one slice, April on the next. Range questions fly with few slices visited. The price: fresh rows all carry today's stamp, so every write rains on the newest slice. The MongoDB guide states the tradeoff plainly: ranged layouts serve range questions well, hashed layouts spread writes.

The third path is a directory. A lookup table records which customer lives on which slice. One edited row grants a giant customer a private slice while small ones share. Flexibility peaks. The price: every request consults the table first. Slow table, slow everyone; dead table, everyone lost. Like a concierge book that serves until the day it vanishes. Teams with uneven customer sizes take this path.

The fourth path is geography. Rows rest near their owners, so European users sit on European servers. Two motives. One is speed, since answers skip the ocean. One is rules, since some records must stay home. Like shopping near home instead of driving across town. The price can be imbalance; an excited region roasts its slice. Teams with regional questions and delay worries use this path.

Now the delicate part: burning keys. Lena's post explodes and millions of likes hammer one slice until it gasps. The fix is salting. Numbers one to ten join id 500, so likes scatter over ten keys. One changed character yields a wholly different hash, so the ten keys fall on varied slices. Profiles and posts stay put; only like load spreads. The price lands on totals: showing the count needs ten reads plus a sum. The rule stays sharp: plain Chris gets no salt, only burning keys do. The CosmicLearn write-up frames the pain with figures: a single partition stalls past a thousand writes a second. And the Amazon piece shows heated partitions splitting on their own.

How does the routing layer decide? Each read stops at the cache first; a hit never reaches the slices. On a miss, or when the request writes, the ball sits with the routing layer. The layer asks two things: does this touch a salted key, and which slice serves. Salted like? One of the ten keys gets picked at random and the like lands there. Total asked? Ten slices get read and added up. Receptionist plus switchboard: the desk answers what it knows and forwards the rest to the right room.

Adding slices hurts under plain remainders. Moving from four slices to five changes nearly every remainder, so nearly everyone packs boxes. Chris and Leo move to new homes. The road taken to grow fills with moving vans. Relief comes from the ring order called consistent hashing. All hash values form a circle, slices stand on it, and the rule walks clockwise from each id to the first slice. A newcomer takes only its neighbor's load; Chris and Leo stay home. Move cost drops from everyone to a single slice. The idea reaches back to a 1997 Karger paper from the Akamai era.

Rings wobble too. Random spots hand wide arcs to some slices and narrow ones to others, and failures dump whole arcs on one neighbor. The fix is virtual spots: seating each slice on the circle ten times over. Slice zero stands at ten separate points, slice one at ten more. Every slice carries scattered small arcs whose totals converge, and failures fan out across all survivors. A field note: Cassandra ran years at 256 spots, then trimmed to 16 to cut upkeep. Few spots mean thin balance, many spots mean heavy care; the sweet spot gets hunted. Tools smooth the rest. The Vitess docs describe online reslicing step by step: fresh slices built, rows copied while writes flow, standby reads shifted, then writes. The Postgres-rooted CitusData docs offer similar live rebalancing. The lesson I keep: sharding is housekeeping, not surgery. When one box cannot hold the rows, when server count will shift, and when move costs are accepted, the ring setup earns its keep. Otherwise a bigger box, good indexes, and a cache buy cheaper peace.