Skip to content

Tensions in Practice: Simple placement in tension with remapping on growth

Hash-based placement · three destinations becoming four

A placement rule assigns each key to a destination using its hash token. Taking the remainder after division by the destination count is simple, but changing that count changes old assignments too. A ring rule gives the new destination a local interval instead. The table keeps six invented tokens fixed and shows which existing homes change under each rule.

Keep placement simple

Derive a destination from the token with little placement metadata.

Limit disruption during growth

Avoid moving unrelated keys whenever another destination joins.

Why these aims pull against each other

A count-dependent rule changes its arithmetic globally. A ring can localize the ownership change, while introducing explicit placement metadata and balance concerns.

Compare the arrangements

Use the destination count

Map each token by modulo 3 before growth and modulo 4 after adding D. Six invented hash tokens. Before: remainder modulo 3 maps 0→A,1→B,2→C. After: modulo 4 adds 3→D. Five selected tokens move; this is not an expected migration fraction.

Six fixed tokens · change the divisor
BeforeAfter
Token 1BBUnchanged
Token 3ADMoved
Token 5CBMoved
Token 7BDMoved
Token 9ABMoved
Token 11CDMoved
What it protects
The rule is compact and needs no ordered ring of owner positions.
What it costs
Five of these six selected tokens change destinations, requiring migration or temporary lookup handling.
When it fits
Fits a stable destination count or a system able to tolerate its remapping cost when the count changes.

Illustration note: The token set is deliberately small and invented. Its five moves are exact arithmetic for this set, not a general statistical estimate.

Give D a ring interval

Retain the old ring positions and insert D between B and C. The same tokens on a clockwise ring 0–11. Original owners A@0, B@4, C@8; each token goes to the next owner, wrapping to 0. Add D@6: only the interval after 4 through 6 changes owner.

Six fixed tokens · insert one ring owner
BeforeAfter
Token 1BBUnchanged
Token 3BBUnchanged
Token 5CDMoved
Token 7CCUnchanged
Token 9AAUnchanged
Token 11AAUnchanged
What it protects
Only token 5 moves in this finite example; the other old assignments remain valid.
What it costs
The ring must be stored and maintained; uneven intervals or token distributions can create load imbalance.
When it fits
Fits changing membership when movement cost matters and ring placement, lookup and migration are correctly managed.

Illustration note: The ring rule is an editorial instantiation of the source’s bounded-arc idea. It omits virtual nodes, replication and failed-owner handling.

What this illustration does—and does not—establish

Hashing: Static Codomain versus Resizing supplies resize remapping and interval-local ownership. The exact finite mapping is calculated from the stated rules, with no empirical throughput claim.

  • Neither table establishes balanced workload; keys can differ greatly in size or demand.
  • Moving ownership does not itself copy data or make concurrent readers find it.
  • Hash collisions and membership agreement are separate responsibilities.

Source entries

Hashing

Prime · Source of the tension

Hashing: Static Codomain versus Resizing supplies the conflict examined here.

Static Codomain versus Resizing

A hash maps into a fixed codomain, but real systems resize — a hash table grows, servers join or leave a shard ring. The tension is temporal: changing the codomain size remaps inputs that were previously stable.

Read the source section

Structural Tensions

Diagnostic: ask whether the codomain is fixed for the system's life; if it can change, use consistent hashing so only a bounded arc of keys remaps rather than the whole set.

Read the source section