<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Consistent-Hashing on Krishnatejaswi S</title>
    <link>https://KTS-o7.github.io/bear/tags/consistent-hashing/</link>
    <description>Recent content in Consistent-Hashing on Krishnatejaswi S</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <managingEditor>shentharkrishnatejaswi@gmail.com (Krishnatejaswi S)</managingEditor>
    <webMaster>shentharkrishnatejaswi@gmail.com (Krishnatejaswi S)</webMaster>
    <copyright>Krishnatejaswi S</copyright>
    <lastBuildDate>Sat, 02 May 2026 00:00:00 +0530</lastBuildDate>
    <atom:link href="https://KTS-o7.github.io/bear/tags/consistent-hashing/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Consistent Hashing: Scaling a Cluster Without Reshuffling the World</title>
      <link>https://KTS-o7.github.io/bear/systems/consistent_hashing/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0530</pubDate><author>shentharkrishnatejaswi@gmail.com (Krishnatejaswi S)</author>
      <guid>https://KTS-o7.github.io/bear/systems/consistent_hashing/</guid>
      <description>&lt;p&gt;The naive approach to distributing keys across N cache nodes is &lt;code&gt;hash(key) % N&lt;/code&gt;. It works fine until you add or remove a node.&lt;/p&gt;&#xA;&lt;p&gt;When N changes to N+1 or N-1, nearly every key remaps to a different node. You go from a warm cache to a cold one in an instant &amp;ndash; a thundering herd of cache misses hitting your database all at once. For a large cluster, that&amp;rsquo;s enough to take down a service.&lt;/p&gt;</description>
      <content:encoded><![CDATA[<p>The naive approach to distributing keys across N cache nodes is <code>hash(key) % N</code>. It works fine until you add or remove a node.</p>
<p>When N changes to N+1 or N-1, nearly every key remaps to a different node. You go from a warm cache to a cold one in an instant &ndash; a thundering herd of cache misses hitting your database all at once. For a large cluster, that&rsquo;s enough to take down a service.</p>
<p>Consistent hashing fixes this. Add or remove a node, and only the keys that were assigned to that node need to move. Everything else stays put.</p>
<h2 id="the-hash-ring">The Hash Ring</h2>
<p>Instead of <code>hash(key) % N</code>, arrange all possible hash values on a ring from 0 to 2^32. Each node gets a position on the ring by hashing its name or ID. To find which node owns a key: hash the key, then walk clockwise around the ring until you hit a node.</p>





<pre tabindex="0"><code>          0
         / \
    Node C   Node A
       |         |
    Node B --- Node D</code></pre><p>Key K hashes to a point on the ring. The first node clockwise from that point owns K.</p>
<p>Now add a new node between B and C. Only the keys that were between B and the new node&rsquo;s position need to move &ndash; from C to the new node. Everything else is unaffected. In an N-node cluster, adding one node moves roughly 1/N of the keys instead of nearly all of them.</p>
<h2 id="virtual-nodes">Virtual Nodes</h2>
<p>Raw consistent hashing has a load distribution problem. With a small number of physical nodes, the gaps between them on the ring are uneven &ndash; one node might own 30% of the keyspace, another 10%. Remove a node and all its load lands on a single neighbor.</p>
<p>Virtual nodes fix this: each physical node gets multiple positions on the ring, typically by hashing it with different suffixes (<code>node1-0</code>, <code>node1-1</code>, <code>node1-2</code>, &hellip;). With enough virtual nodes per physical node, the load distributes evenly across the ring. Removing one node scatters its keys across many neighbors rather than dumping them all on one.</p>
<p>This is the production configuration in every serious deployment.</p>
<h2 id="where-its-used">Where It&rsquo;s Used</h2>
<ul>
<li><strong>Amazon DynamoDB</strong> &ndash; consistent hashing across storage nodes, virtual nodes for even distribution</li>
<li><strong>Apache Cassandra</strong> &ndash; the token ring is consistent hashing; each node owns a range of tokens</li>
<li><strong>Memcached</strong> &ndash; the ketama client implements consistent hashing for cache node assignment</li>
<li>Basically every distributed cache or storage system that needs to scale nodes without full reshuffling</li>
</ul>
<p>The pattern generalizes beyond caching. Any system that needs to assign work or data to nodes &ndash; and occasionally add or remove nodes &ndash; runs into the same problem. Consistent hashing is the standard solution.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
