---
title: 'Scaling Writes: Part 3 of 4 — Queues & Load Shedding'
source: 'https://youtube.com/watch?v=K5AdUe5Eu-Y'
video_id: 'K5AdUe5Eu-Y'
date: 2026-08-04
duration_sec: 111
---

# Scaling Writes: Part 3 of 4 — Queues & Load Shedding

> Source: [Scaling Writes: Part 3 of 4 — Queues & Load Shedding](https://youtube.com/watch?v=K5AdUe5Eu-Y)

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

### Key Points

- **Predictable vs. Unpredictable Spikes** [00:01] — 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.
- **Two Options: Buffer or Drop** [00:29] — 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.
- **Buffering is Async and Temporary** [00:56] — 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.
- **Load Shedding: Dropping Low-Value Writes** [01:11] — 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.
- **Strategy: Buffer Bursts, Shed Junk, Protect What Matters** [01:24] — 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.

### Conclusion

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.

## Transcript

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
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
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
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.
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.
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
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
matters. This is part three of four of our scaling rights series. Follow for breakdown on our website, hellointerview.com.