Fix a Database Overloaded by a Viral Ad
45sRelatable real-world problem with a clear, actionable solution (salting) that viewers can immediately understand and apply.
▶ Play ClipAI 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.
Chapters
[00:02]
The Hot Partition Problem
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.
[00:17]
Salting as a Solution
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.
[00:49]
Read Trade-off
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.
[01:02]
Interview Relevance
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.
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.
Mentioned in this Video
Study Flashcards (3)
What is the hot partition problem?
easy
Click to reveal answer
What is the hot partition problem?
easy
Click to reveal answer
When a single item (like a viral ad) receives a disproportionate amount of traffic, causing all writes to go to the same shard and overloading it.
00:02
What is salting in database sharding?
medium
Click to reveal answer
What is salting in database sharding?
medium
Click to reveal answer
Appending a random number to a key (e.g., ad ID) to create sub-partitions, spreading writes across multiple nodes.
00:17
What is the trade-off of salting?
medium
Click to reveal answer
What is the trade-off of salting?
medium
Click to reveal answer
Reads become more complex because queries must fan out to all sub-partitions and merge results.
00:49
💡 Key Takeaways
🔧
Salting technique
Provides a concrete, actionable solution to a common scalability problem, showing practical expertise.
00:17
💡
Interview value
Highlights how demonstrating trade-offs and fan-out can impress interviewers, adding career value.
01:02Full Transcript
[00:02] 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
[00:17] 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,
[00:34] 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
[00:49] 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
[01:02] 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
[01:18] 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.
