feat: integrate system design

2026-11-02 13:12:44 +00:00 · 2026-10-07 14:18:14 -04:00
1 parent e14432d32a
commit cb4a03b6fa
@@ -0,0 +1,137 @@
+---
+title: "Design Consistent Hashing"
+description: "Spread keys across servers on a hash ring so that adding or removing a server moves only a small share of the keys."
+icon: orbit
+sidebar:
+  label: "Consistent Hashing"
+---
+
+## Introduction
+This chapter explores consistent hashing, a technique essential for achieving horizontal scaling by efficiently distributing requests and data across servers. It minimizes data redistribution when servers are added or removed and ensures an even distribution of data to mitigate issues like server hotspots.
+
+## The Rehashing Problem
+### Explanation
+In traditional hashing methods, such as `serverIndex = hash(key) % N`, data redistribution becomes problematic when the number of servers changes. For example:
+- Removing a server causes most keys to be reassigned, leading to cache misses.
+- Adding a server results in unnecessary key redistributions.
+
+  <Frame caption="Server hashing">
+
+  ![Server hashing](./images/consistent-hashing/server-hashing.png)
+
+  </Frame>
+
+- This approach works well when the size of the server pool is fixed. However, problems arise when new servers are added, or existing servers are removed.
+
+  <Frame caption="Server hashing Miss">
+
+  ![Server hashing Miss](./images/consistent-hashing/server-hashing-miss.png)
+
+  </Frame>
+
+### Key Issue
+Redistribution of most keys when server count changes causes inefficiency and overload.
+
+## Consistent Hashing
+### Definition
+Consistent hashing ensures that only a fraction of keys are remapped when servers are added or removed. This minimizes disruptions and enhances scalability.
+
+### Key Concepts
+1. **Hash Space and Ring:** The hash space forms a continuous ring, with hash values distributed from `0` to `2^160-1` (e.g., using hash function like SHA-1). By connecting both ends we get a ring.
+
+   <Frame caption="Hash Ring">
+
+   ![Hash Ring](./images/consistent-hashing/hash-ring.png)
+
+   </Frame>
+
+- Using the same hash function f, we map servers based on server IP or name onto the ring.
+
+  <Frame caption="Server Ring">
+
+  ![Server Ring](./images/consistent-hashing/server-ring.png)
+
+  </Frame>
+
+1. **Server Lookup**
+- A key's server is determined by traversing clockwise on the ring until a server is found.
+
+  <Frame caption="Server Lookup">
+
+  ![Server Lookup](./images/consistent-hashing/server-lookup.png)
+
+  </Frame>
+
+2. **Adding and Removing Servers**
+- Adding a server redistributes only nearby keys. Only a fraction of keys are redistributed to the new server.
+
+  <Frame caption="Adding Server">
+
+  ![Adding Server](./images/consistent-hashing/adding-server.png)
+
+  </Frame>
+
+- Removing a server affects only the keys in its range. Only keys from the removed server are reassigned to the next server clockwise.
+
+  <Frame caption="Removing Server">
+
+  ![Removing Server](./images/consistent-hashing/removing-server.png)
+
+  </Frame>
+
+## Challenges and Solutions
+### Two Issues in Basic Approach
+1. **Uneven Partition Sizes:** Servers may have unequal data partitions.
+2. **Non-uniform Key Distribution:** Some servers may receive significantly more keys than others.
+
+### Solution: Virtual Nodes
+- Each server is represented by multiple virtual nodes on the ring uniformly distrubuted on the ring.
+- Virtual nodes improve key distribution and balance load. As the number of virtual nodes increases, the distribution of keys       becomes more balanced. This is because the standard deviation gets smaller with more virtual nodes, leading to balanced data distribution.
+
+  <Frame caption="Virtual Nodes">
+
+  ![Virtual Nodes](./images/consistent-hashing/virtual-nodes.png)
+
+  </Frame>
+
+## Affected Keys
+When servers are added or removed:
+- **Added Server:** Affected keys are those between the new server and its predecessor.
+  In the following example server 4 is added onto the ring. The affected range starts from s4 (newly
+  added node) and moves anticlockwise around the ring until a server is found (s3). Thus, keys
+  located between s3 and s4 need to be redistributed to s4.
+
+  <Frame caption="Server Addition">
+
+  ![Server Addition](./images/consistent-hashing/server-addition.png)
+
+  </Frame>
+
+- **Removed Server:** Affected keys are those between the removed server and its predecessor. In the following example when a server (s1) is removed, the affected range starts from s1
+(removed node) and moves anticlockwise around the ring until a server is found (s0). Thus, keys located between s0 and s1 must be redistributed to s2.
+
+<Frame caption="Server Removed">
+
+![Server Removed](./images/consistent-hashing/server-removed.png)
+
+</Frame>
+
+## Benefits of Consistent Hashing
+- **Minimized Redistribution:** Only a fraction of keys are reassigned.
+- **Scalability:** Enables horizontal scaling.
+- **Mitigates Hotspots:** Balances data distribution to avoid server overload.
+
+## Real-World Applications
+- Amazon Dynamo DB
+- Apache Cassandra
+- Discord
+- Akamai CDN
+- Maglev Load Balancer
+
+## Further reading
+
+- [Consistent Hashing](https://tom-e-white.com/2007/11/consistent-hashing.html)
+- [CS168: Introduction and Consistent Hashing](http://theory.stanford.edu/~tim/s16/l/l1.pdf)
+- [Apache Cassandra](http://www.cs.cornell.edu/Projects/ladis2009/papers/Lakshman-ladis2009.PDF)
+- [Scaling Discord](https://blog.discord.com/scaling-elixir-f9b8e1e7c29b)
+- [Google Maglev](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf)