Black Friday vs. Viral Spikes: How to Survive
43sRelatable real-world scenarios (Black Friday, viral posts) make this instantly engaging for anyone dealing with traffic spikes.
▶ Play ClipAI Summary
This video, part three of a four-part series on scaling writes, addresses how to handle unpredictable traffic spikes in system design. It contrasts two primary strategies: buffering writes through a queue (like Kafka or SQS) and load shedding by dropping less critical data. The presenter emphasizes protecting valuable data while managing bursts effectively.
Chapters
[00:01]
Predictable vs. Unpredictable Spikes
Some events like Black Friday are predictable and can be scaled for in advance, but unpredictable spikes (e.g., viral links) cause capacity scrambling. Auto scaling is insufficient because spinning up a box takes minutes and scaling a database often causes downtime.
[00:29]
Two Options: Buffer or Drop
The two real options for handling spikes are buffering (using a queue) or dropping (load shedding). Buffering involves a write queue like Kafka or SQS between the app and database, allowing the app to respond instantly while workers drain the queue at a sustainable pace.
[00:56]
Buffering is Async and Temporary
Buffering makes the system asynchronous and is only a temporary fix. If writes continue to outpace workers draining the queue, the queue grows indefinitely, turning a burst into a full-blown outage.
[01:11]
Load Shedding: Dropping Low-Value Writes
Load shedding involves discarding the least valuable writes. For example, Uber driver location updates can be dropped with minimal impact, but user-created posts must never be dropped.
[01:24]
Strategy: Buffer Bursts, Shed Junk, Protect What Matters
In a high-stress interview scenario, the recommended approach is to buffer bursts, shed low-value data, and protect critical writes. This is part three of a four-part series, with more content on hellointerview.com.
The key takeaway is to buffer bursts with a queue and shed low-value writes to protect critical data during traffic spikes. This approach balances responsiveness and reliability, essential for system design interviews.
Mentioned in this Video
Study Flashcards (5)
What are the two main strategies for handling traffic spikes in system design?
easy
Click to reveal answer
What are the two main strategies for handling traffic spikes in system design?
easy
Click to reveal answer
Buffering (using a queue) and dropping (load shedding).
00:29
Why is auto scaling insufficient for handling spikes?
medium
Click to reveal answer
Why is auto scaling insufficient for handling spikes?
medium
Click to reveal answer
Spinning up a box takes minutes and scaling a database often causes downtime or degraded performance during the spike.
00:15
What is the main risk of buffering writes in a queue?
medium
Click to reveal answer
What is the main risk of buffering writes in a queue?
medium
Click to reveal answer
If writes continue to come in faster than workers drain the queue, the queue grows forever and the burst turns into a full-blown outage.
00:56
Give an example of a write that can be safely dropped (load shedding).
easy
Click to reveal answer
Give an example of a write that can be safely dropped (load shedding).
easy
Click to reveal answer
Uber driver location updates, because missing one update only loses a little accuracy.
01:11
What is the recommended strategy for handling bursts in a system design interview?
easy
Click to reveal answer
What is the recommended strategy for handling bursts in a system design interview?
easy
Click to reveal answer
Buffer the bursts, shed the junk, and protect what matters.
01:24
💡 Key Takeaways
⚖️
Buffer or Drop
Presents the core decision framework for handling spikes, a fundamental system design principle.
00:29
💡
Buffering is Temporary
Highlights a common misconception that queues are a permanent solution, emphasizing their temporary nature.
00:56
🔧
Load Shedding Example
Concrete example of dropping low-value data (Uber locations) illustrates the concept clearly.
01:11Full Transcript
[00:01] embarrassing proportion of the time. How do you handle Black Friday or the end of the auction or the Super Bowl? Some events are predictable. You can definitely anticipate Black Friday and scale up your system in advance. But
[00:15] some are less so, like a link going viral or a celebrity post might mean you're scrambling for capacity. Many candidates I interview will reach for auto scaling. And this is kind of a solution, but spinning up a box takes
[00:29] minutes and scaling a database often means downtime or degraded performance during the spike. This is exactly when you can't afford it. So, you've got two real options, buffer or drop. Buffering in a system design setting usually means
[00:43] in a system design setting usually means a right queue. This is like Kafka or SQS between the app and the database. The app drops the right on the queue and responds instantly. Workers drain it at a sustainable pace.
[00:56] This is often times a good solution, but you need to know it's now async and it's only a temporary fix. If rights continue to come in faster than the workers drain, the queue grows forever and your burst turns into a full-blown outage.
[01:11] Dropping is often called load shedding. This sounds stupid, but it's actually really smart. We can throw away the least valuable rights. Uber drivers are reporting their location every few seconds. If we miss
[01:24] one update, we've only lost a little bit of accuracy. But we never want to drop a post that gets created. So, you've got a burst or a high-stress moment in your interview, buffer the bursts, shed the junk, and protect what
[01:38] matters. This is part three of four of our scaling rights series. Follow for breakdown on our website, hellointerview.com.
