https://hackerpaper.kaipfister.de/p/1908.08762/Collected HN comments and submissions linking this paper.enMon, 02 Nov 2026 11:16:22 GMThttps://news.ycombinator.com/item?id=45240091urn:hackerpapers:mention:1908.08762:45240091Sun, 14 Sep 2025 14:40:13 GMT<p>How we run it: Auto-scaled Kubernetes deployments, one for each availability zone, currently on m*gd instances which give us local NVMe. The pods are able to easily push GiBps with 1-2 CPUs used — network is the bottleneck so we made it a scaling dimension (thanks KEDA). On the client side, each gateway process uses kube.rs to watch ready endpoints in the same zone as itself, and frequently polls /stats exposed by Cachey for recent network throughput as a load signal. To improve hit rates with key affinity, clients use rendezvous hashing for picking a node, with bounded load…</p><p><a href="https://hackerpaper.kaipfister.de/p/1908.08762/">Paper and discussion history</a>. A mention is not an endorsement.</p>cs.DShttps://news.ycombinator.com/item?id=40415826urn:hackerpapers:mention:1908.08762:40415826Mon, 20 May 2024 14:27:11 GMT<p>This is a very cool page. I love little simulations like this for building intuition for systems problems. Practical systems deal with this by not caring strongly about overflow (caches), by running at low enough utilizations that overflow is very unlikely given their item counts (e.g. Dynamo), by using explicit partitioning rather than consistent hashing (e.g. DynamoDB), by being able to take advantage of multi-tenancy to drive up per-physical-node utilization even in the case of low per-logical-node utilization, or by using some additional algorithmic sophistication (e.g. Chen et al…</p><p><a href="https://hackerpaper.kaipfister.de/p/1908.08762/">Paper and discussion history</a>. A mention is not an endorsement.</p>cs.DS