--- title: "Consistent hash peak-to-average load ratio" description: "Estimate the busiest node from ring variance, then compare virtual nodes, multi-probe hashing, and bounded loads for a target peak ratio." canonical_url: "https://fanout.sh/blog/consistent-hash-peak-to-average-load-ratio" md_url: "https://fanout.sh/blog/consistent-hash-peak-to-average-load-ratio.md" last_updated: "2026-09-27" access: "public" --- # Consistent hash peak-to-average load ratio Estimate the busiest node from ring variance, then compare virtual nodes, multi-probe hashing, and bounded loads for a target peak ratio. - Author: Suraj Gaud - Published: 2026-09-27 - Track: System design - Access: Public - Tags: consistent hashing, peak-to-average load, virtual nodes, multi-probe hashing, bounded loads, load balancing, distributed systems Consistent hash peak-to-average load ratio asks how far the busiest node sits above the fleet mean. It is not the same as the ownership variance of one named node. A ring with 100 virtual nodes per server has about 10% relative standard deviation for one server. Across 1,000 servers, the maximum gets 1,000 chances to land in the tail, so 1.10 is not a credible peak target. Use the one-node formula for a first estimate, add a fleet-maximum correction, then test the actual ring. If that cost is too high, extra key probes or an explicit capacity bound may fit the requirement better. ## Consistent hash peak-to-average load ratio The[multi-probe consistent hashing paper](https://arxiv.org/abs/1505.00062)defines the metric as maximum node load divided by average node load. If 1,000 nodes own equal traffic, average load is one thousandth of the total. A peak ratio of 1.20 means the busiest node receives 20% more than that average. The metric can refer to continuous hash-space share, key count, stored bytes, requests, or CPU work. Name the load unit before comparing algorithms. Virtual nodes directly smooth hash-space ownership. They do not split one hot key, make object sizes equal, or make every request cost the same. Fanout's[virtual-node variance guide](/blog/consistent-hash-virtual-node-count-variance)derives the marginal ownership distribution. The next step is converting that distribution into a fleet maximum. ## One-node variance is not the fleet maximum For N equal nodes and V independently hashed virtual nodes per node, one node's ownership share has mean 1/N. Its coefficient of variation is the square root of (N minus 1) divided by (N times V plus 1). For a large fleet, this is close to 1 divided by the square root of V. That CV describes a preselected node. Capacity planning cares about the maximum of N correlated shares. A useful first approximation treats the shares as nearly normal and places the maximum about square root of (2 ln N) standard deviations above the mean. The resulting peak ratio estimate is 1 plus square root of (2 ln N divided by V). It is a sizing heuristic, not a probability guarantee. Ring shares are dependent because they must sum to one. Their upper tail is not exactly normal, especially when V is small. Use the approximation to reject obviously undersized rings. Use repeated ring construction to set the production value. ## Work a 1.10 target across 1,000 nodes Take N = 1,000 and ask for a peak-to-average ratio near 1.10. The one-node shortcut would set V near 1 divided by 0.10 squared, or 100 virtual nodes. That only makes one node's standard deviation about 10% of the mean. The fleet approximation instead solves V near 2 ln(1,000) divided by 0.10 squared. The result is about 1,382 virtual nodes per physical node. At V = 100, the same approximation gives a peak ratio near 1.37. At V = 1,382, it gives roughly 1.10. These numbers expose the missing ln N term. Holding per-node CV fixed while growing the fleet gives randomness more chances to produce an extreme owner. The estimate still needs a tail target. A median maximum and a 99.9th-percentile maximum are different requirements. Build many rings with the production hash and node naming scheme. Record the maximum share for every ring, then select V from the required percentile. ## Price virtual nodes as metadata and updates A ring stores N times V positions. With a 64-bit hash and a 64-bit owner identifier, the compact payload floor is 16 bytes per position. For 1,000 nodes and V = 1,382, that floor is about 22.1 MB. Tree nodes, object headers, alignment, and duplicate indexes can make the resident set larger. Lookup remains a binary search over 1.382 million positions. Membership updates must insert or remove 1,382 positions for one physical node. The[multi-probe paper](https://arxiv.org/abs/1505.00062)gives a harsher comparison for a 1.05 target. Its ring used 700 ln N positions per node. At 1,000 nodes, the experiment used 4,835 positions per node. At 10,000 nodes, it used 6,447 per node and reported a 1.4 GB table. The same paper's lower virtual-node setting, J = ln N, converged to a peak ratio near e rather than 1.05. More points buy balance through state. The cost appears in memory, cache misses, initialization, control-plane updates, and recovery-range bookkeeping. ## Multi-probe spends lookups instead of ring points Multi-probe consistent hashing stores each node once, then hashes each key to K candidate positions and chooses the closest successor. The paper shows a peak ratio of 1 plus epsilon with about 1 plus 1 divided by epsilon lookups per key. A 1.10 target uses epsilon = 0.10, so K = 11. A 1.05 target uses K = 21. Its experiments with K = 21 reported median peak ratios near 1.05 from 100 through 100,000 nodes. The 99th percentile was 1.10 at 100 nodes and 1.06 from 1,000 upward. That balance used constant metadata per node, but assignment took several hundred nanoseconds in the paper's uncontended-cache benchmark. The ordinary ring was faster per lookup because it made one table search. Its large table paid in memory and construction instead. This is a direct exchange: virtual nodes spend state before requests arrive, while multi-probe spends more hash and lookup work on each request. ## Bounded loads turns the ratio into a capacity rule Another option makes the target explicit. Set each node's capacity to 1 plus epsilon times average, then skip full nodes while walking the ring. The[consistent hashing with bounded loads paper](https://research.google/pubs/consistent-hashing-with-bounded-loads/)guarantees that no node exceeds the selected capacity. For N clients and N servers, the paper obtains maximum load 2 while moving an expected constant number of clients per update. For a general capacity factor c = 1 plus epsilon, its expected movement overhead grows by a factor on the order of 1 divided by epsilon squared when epsilon is at most one. The[Google Research explanation](https://research.google/blog/consistent-hashing-with-bounded-loads/)describes the operational trade. Tighter spare capacity improves uniformity but can make an update walk farther and move more assignments. Bounded loads needs current occupancy and a policy for what counts toward capacity. It is not the same stateless mapping as a plain ring. Use it when the maximum is a hard constraint and the system can maintain the extra state. Use a probabilistic ring when decentralized agreement and simple lookup matter more. ## Finite keys and hot work add another peak Hash-space ownership becomes visible only through a finite key set. Even a perfectly equal ring can receive unequal key counts from sampling. If objects have different sizes, equal key counts can still create a byte hotspot. If request rates follow a heavy tail, one key can dominate a node whose ownership share is ordinary. No virtual-node count can split one indivisible hot key. Replication, request-aware routing, or a second partitioning layer must handle that case. Measure four peak ratios separately: hash-space share, key count, stored bytes, and request work. The[basic consistent hashing walkthrough](/blog/consistent-hashing-explained-simply)shows why a key moves to one clockwise owner. The same rule explains why one hot key remains concentrated. The[weighted rendezvous comparison](/blog/weighted-rendezvous-vs-consistent-hash-ring)covers capacity weights. Weights correct expected ownership for unequal machines, but they do not remove workload skew within each share. ## Choose the mechanism from the bound Start with the exact statement the service needs. Write the load unit, fleet size, acceptable ratio, percentile, membership churn, and lookup budget. For an ordinary ring, estimate V with 2 ln N divided by (ratio minus 1) squared. Treat that as a lower-cost screening calculation, then simulate. Benchmark the resulting index after it exceeds processor cache. Measure lookup latency, rebuild time, update fanout, and recovery after removing the busiest node. Compare multi-probe at K = 1 plus 1 divided by epsilon. Compare bounded loads when the peak must never cross a declared capacity. Keep the[Jump Hash tradeoff](/blog/jump-consistent-hash-vs-hash-ring)in the matrix when nodes use sequential identifiers and arbitrary removals are not required. The peak-to-average ratio is a fleet statistic. A per-node variance setting becomes useful only after the fleet maximum, metadata cost, lookup work, and real workload skew are evaluated together. --- This representation contains public Fanout content only. Protected Pro lessons, account data, billing, checkout, and pricing are not included. Browse the public content map: https://fanout.sh/sitemap.md