Range Sharding

The Mechanism

 each node owns a CONTIGUOUS key range:

 node A: user_id     [1 – 1M)
 node B: user_id     [1M – 2M)
 node C: user_id     [2M – ∞)

 or by time:

 node A: events [2026-01)   node B: events [2026-02) ...

 routing = binary search over the range table (directory).
 adjacent keys live together — ORDER IS PRESERVED.

What Ordering Buys

 ✓ RANGE SCANS: "users A through D" touches ONE node
 ✓ TIME SERIES: recent data co-located; scans are sequential
 ✓ EXPIRY: old time-range = DROP the whole shard/partition
   (vs delete-millions-of-rows)
 ✓ CURSOR PAGINATION: ordered walks stay single-shard
 ✓ LOCALITY: alphabetically/temporally related data shares
   cache pages

 time-series + event-log workloads are range sharding's
 home turf for exactly these reasons.

The Hotspot Physics

 monotonic keys concentrate writes on ONE node:

 sequential ids: every INSERT → rightmost range → last shard
 timestamps:     all of TODAY's writes → today's shard

 [shard-1: idle] [shard-2: idle] [shard-3: ON FIRE]

 the entire cluster performs like one node for writes —
 distribution achieved nothing. this failure is GUARANTEED
 with time/sequence keys, not a risk.

 mitigations:
 - hash-compound: shard by hash(entity), range within
 - SALTING: shard_key = time + hash(bucket)%16 prefix
   → spreads across 16 shards, merge on read (scan all buckets)
 - accept it for LOW write volume + high read-recency value

Split and Merge Mechanics

 ranges aren't static — they split under load:

 node B overloaded at [1M–2M):
   pick median key ~1.5M → split into [1M–1.5M), [1.5M–2M)
   migrate half to fresh node; update directory
 
 distributed systems do this AUTOMATICALLY (Spanner/Cockroach/
 HBase): hot ranges split, cold ranges merge, directory updates.
 
 you still must design FOR it:
 - avoid max-size single rows (split points between keys!)
 - monitor per-range load to catch pre-split skew

Hash vs Range Decision Recap

 ask TWO questions:

 1. Do queries NEED key ranges/order?  
      yes → range (or compound hybrid)
      no  → hash
 2. Are keys monotonically increasing?
      yes + high write rate → hash/salting REQUIRED
      no                    → range safe

 time-series answer: usually BOTH — range by day,
 salt/hash within day if writers are many.

Interview Framing

Range-sharding answers score when hotspot physics leads: “sequential keys put every insert on the final shard — guaranteed, not probabilistic” then mitigations (salting arithmetic included), THEN the wins list (scans/expiry/cursors). Leading with the win list gets ambushed by the follow-up; leading with the failure mode demonstrates you’ve operated both.