Change the Problem, Not Absorb It
44sIt presents a counterintuitive staff-level mindset that challenges typical scaling approaches, sparking curiosity and debate.
▶ Play Clip"Delivers on the promise of explaining batching and aggregation, though it's a short teaser for a larger pattern breakdown."
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.
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.
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.
Batching only helps if there are multiple events per key per window. If you get one like an hour, batching buys you nothing.
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.
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.
What is the core idea of batching in scaling writes?
Make fewer, bigger writes instead of handling each write individually, as databases process batches more efficiently.
00:16
How does a like batcher work?
It watches a 1-minute window, tabulates likes per post, and writes the totals, reducing 100 likes to 1 write.
00:43
When does batching not help?
When there is only one event per key per window, such as one like an hour.
00:57
What architecture is used for extreme scale like a celebrity post?
A layer of processors that aggregate on the way in and broadcast nodes that fan out on the way out.
01:13
Batching reduces write count
Key technique for scaling writes by reducing database load.
00:16Batching has limitations
Important caveat that batching only works with high event density.
00:57Aggregation and broadcast for extreme scale
Shows a scalable architecture for massive write loads.
01:13[00:02] 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
[00:16] 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
[00:30] 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
[00:43] 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
[00:57] 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
[01:13] 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
[01:27] the whole pattern breakdown on our website hellointerview.com.
⚡ Saved you 0h 01m reading this? Transcribe any YouTube video for free — no signup needed.