# Hot Keys, Scalability, and the Zipf Distribution

DevFeed: [Hot Keys, Scalability, and the Zipf Distribution](<https://devfeed.tech/articles/hot-keys-scalability-and-the-zipf-distribution-12533.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2023/02/07/hot-keys.html>)

Author: Marc Brooker

Published: 2023-02-07T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Scalability](<https://devfeed.tech/topics/scalability.md>), [Database](<https://devfeed.tech/topics/database.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Microservice](<https://devfeed.tech/topics/microservice.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [database](<https://devfeed.tech/tags/database.md>), [latency](<https://devfeed.tech/tags/latency.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

The article explains why distributed databases and similar systems can fail to scale when access is concentrated on hot keys or hot items. It uses sharding and an example based on uneven baby-name popularity to show how a heavily accessed partition can become a bottleneck, causing errors or latency even when additional capacity is added elsewhere. It then introduces random request variation as a balls-into-bins problem and discusses simulation as a way to study overload.

## Source excerpt

Hot Keys, Scalability, and the Zipf Distribution the: so hot right now. Does your distributed database (or microservices architecture, or queue, or whatever) scale? It's a good question, and often a relevant one, but almost impossible to answer. To make it a meaningful question, you also need to specify the workload and the data in the system. Given this workload, over this data, does this database scale? One common reason systems don't scale is because of hot keys or hot items: things in the system that are accessed way more often than the average thing. To understand why, lets revisit our database architecture from the previous post: Sharding, the horizontal dimension in this diagram, only works if the workload is well distributed over the key space. If some keys are too popular or too hot, then their associated shard will become a bottleneck for the whole system. Adding more capacity will increase throughput for other keys, but the hottest ones will just experience errors or latency. In this post, we'll look at some examples to understand how much of a bottleneck this actually is. Say hello to Olivia and Liam If you were born in the USA in 2021, there's about a 1% chance your name is either Olivia or Liam1, or about a 0.01% chance your name is Blaise or Annabella. Baby names come in waves and fashions, and so some are always much more popular than others3. Now, imagine we were using the baby's first name as a database key. Clearly, that would skew accesses heavily towards Olivia's partition, affecting throughput for the whole database. But how much of a practical concern is that effect? Let's start by building our intuition. For simplicity we're going to consider just girls. We'd expect about 1% of babies to be called Olivia, and at least 1% of traffic then going to Olivia's partition. So, if we're trying to avoid errors or latency caused by overloading that partition, we'd expect that by the time the database was handling $\approx \frac{1}{0.01} = 100$ times the