---
title: 'Scaling Writes: Part 4 of 4 — Batching & Aggregation'
source: 'https://youtube.com/watch?v=ep_-AFZ_SMw'
video_id: 'ep_-AFZ_SMw'
date: 2026-08-04
duration_sec: 96
---

# Scaling Writes: Part 4 of 4 — Batching & Aggregation

> Source: [Scaling Writes: Part 4 of 4 — Batching & Aggregation](https://youtube.com/watch?v=ep_-AFZ_SMw)

## Summary

This video is the fourth part of a series on scaling writes in system design, focusing on batching and aggregation techniques. It explains how to reduce the number of database writes by grouping them, using examples like a like button on a viral post, and mentions a layer of processors and broadcast nodes for extreme scale.

### Key Points

- **Batching as a scaling strategy** [00:02] — Batching makes fewer, bigger writes instead of handling each write individually. Databases process batches more efficiently than individual writes due to OS and hardware behavior.
- **Like batcher example** [00:30] — For a viral post with thousands of likes per second, a like batcher watches a 1-minute window, tabulates likes per post, and writes totals. This reduces 100 writes to 1 if there are 100 likes in that window.
- **Limitations of batching** [00:57] — Batching only helps if there are multiple events per key per window. If you get one like an hour, batching buys you nothing.
- **Extreme scale with aggregation and broadcast** [01:13] — For a celebrity post with a million live viewers, add a layer of processors that aggregate on the way in and broadcast nodes that fan out on the way out, reducing writes to 100 times fewer destinations.

### Conclusion

Batching and aggregation are powerful techniques to scale writes by reducing the number of database operations, but they are only effective when there is sufficient event density per key.

## Transcript

about scaling rights beyond what a new database, sharding, or queues will handle, staff-level candidates will change the shape of the problem instead of just absorbing it. How do you do this? One way is batching. Most ways of
scaling rights just take the rights as they come and find somewhere to put them. This one's different. It makes fewer, bigger rights. Databases process a batch way more efficiently than the same rights one at a time. This relates
to how operating systems and hardware function. Picture a viral post getting liked thousands of times a second, each with a separate right. Instead of hammering the database, put a like batcher in front of it. It watches a
1-minute window, tabulates likes per post, and writes the totals. A post gets 100 likes in that window, you went from 100 rights to one. But this only helps if you actually get multiple events per key per window. If
you get one like an hour, batching buys you nothing. This works at the extreme. A celebrity post with a million live viewers all commenting and liking at each viewer. You add a layer of processors that
aggregate on the way in and broadcast nodes that fan out on the way out. Now, each node is writing to 100 times less destinations. Want to hear more about how to scale rights in system design interviews? View
the whole pattern breakdown on our website hellointerview.com.