[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.