---
title: 'How to Fix a Database Overloaded by a Viral Ad'
source: 'https://youtube.com/watch?v=9j4K_Gu0ZdI'
video_id: '9j4K_Gu0ZdI'
date: 2026-08-04
duration_sec: 96
---

# How to Fix a Database Overloaded by a Viral Ad

> Source: [How to Fix a Database Overloaded by a Viral Ad](https://youtube.com/watch?v=9j4K_Gu0ZdI)

## Summary

This video explains the database hot partition problem that occurs when a single item, like a viral ad, receives a disproportionate amount of traffic. It introduces the technique of 'salting' as a solution, which distributes writes across multiple sub-partitions to prevent any single node from being overwhelmed, while acknowledging the trade-off of increased read complexity.

### Key Points

- **The Hot Partition Problem** [00:02] — A viral ad causes 10,000 clicks per second all targeting the same ad ID. If the database is sharded by ad ID, all writes go to the same shard, overloading it.
- **Salting as a Solution** [00:17] — Salting appends a random number (0-9) to the ad ID, creating sub-partitions (e.g., 4560-4569). This spreads writes evenly across 10 sub-partitions, preventing any single node from being crushed.
- **Read Trade-off** [00:49] — The trade-off is on the read side: queries for click totals must fan out to all 10 buckets and merge results, increasing read complexity but allowing writes to scale.
- **Interview Relevance** [01:02] — Salting is a great answer for system design interview questions about handling skewed traffic. Demonstrating the trade-off and fan-out shows senior-level thinking.

### Conclusion

Salting is an effective technique to handle hot partitions by distributing writes, but it requires accepting more complex read operations. This pattern is valuable for system design interviews and real-world scalability.

## Transcript

database. Nike drops a LeBron ad, it goes everywhere. Suddenly your system is getting 10,000 clicks per second all for the same ad ID. Now you're not stupid, so you've sharded your database, but you're partitioning by ad ID, so every
single one of those rights goes to the same shard. Shard number three is on fire. One fix is called salting. Instead of partitioning by ad ID alone, you append a random number, say from zero to nine. So ad ID 456 becomes 4560,
nine. So ad ID 456 becomes 4560, 4561, 4562, all the way to 4569. Now those 10,000 rights spread evenly across 10 sub-partitions. No single node gets crushed. The trade-off here is on the read side. When an advertiser queries
read side. When an advertiser queries click totals for ad 456, you can't just read one partition anymore. You fan out to all of those 10 buckets and merge, or just going to add the results. There's more read complexity here, but your
rights scale. This is often a great answer for when an interviewer asks, "What if one ad gets 100 times the traffic?" Salting trades read simplicity you're going to just name that trade-off, explain the fan out, the read
just shown senior-level thinking on a problem most candidates miss entirely. Learn more about handling massive rights in our scaling rights pattern on Hello Interview. Follow us for more system design.