---
title: 'Scaling Writes: Part 2 of 4 — Sharding & Partitioning'
source: 'https://youtube.com/watch?v=A2y3EmVc8nU'
video_id: 'A2y3EmVc8nU'
date: 2026-08-04
duration_sec: 94
---

# Scaling Writes: Part 2 of 4 — Sharding & Partitioning

> Source: [Scaling Writes: Part 2 of 4 — Sharding & Partitioning](https://youtube.com/watch?v=A2y3EmVc8nU)

## Summary

This video explains the concept of sharding for scaling database writes to handle millions of concurrent requests, a common topic in system design interviews. It covers the importance of choosing a good partition key, the trade-offs between read and write scaling, and the need to consider how many shards a request touches.

### Key Points

- **Sharding as the answer** [00:02] — Sharding is the expected answer for scaling to millions of concurrent writes. It involves splitting a large database into multiple servers, where each server handles a portion of the writes.
- **Linear scaling example** [00:16] — If one server handles 1,000 writes per second, 10 servers can handle 10,000 writes per second, demonstrating linear scaling.
- **Partition key importance** [00:31] — The partition key is the field hashed to determine which shard a row lands on. A good key spreads writes evenly, while a poor key (e.g., partitioning by country) can lead to hotspots like a busy China shard and idle New Zealand shard.
- **Read vs. write trade-off** [00:57] — Sharding for writes may complicate reads. If writes spread perfectly but every read must hit all 100 shards, a new problem is created. Caching can help with read scaling, but it's crucial to ask how many shards a request touches and how often.
- **Conclusion and next steps** [01:11] — If you choose a partition key well and consider consequences, you're in good shape. This is part 2 of a series on scaling writes; more content is available on hellointerview.com.

### Conclusion

Effective sharding requires careful partition key selection and awareness of its impact on read patterns. This video provides a concise overview for system design interview preparation.

## Transcript

you to scale to millions of concurrent rights, there's one answer almost every interviewer will expect, but most candidates fumble. Sharding. Picture a social app where every post, like, and view is written to one big database.
That one box can't keep up anymore, so we go to split it into multiple servers. If one server handles a thousand rights a second, 10 servers handles 10,000. immediately expect another question from your interviewer. How do you pick the
partition key? That's the field you hash to decide which shard a row lands on. If you pick this well, the rights spread evenly, which means higher utilization and better scaling. If you pick poorly, like
partitioning by country, and your China shard is on fire while New Zealand sits idle. Sharding is not a free lunch. If you sharded this all for a write bottleneck, you may have made your read problem
harder. If writes spread perfectly, but every read has to hit all 100 shards, you've created a new problem. That problem might be easier to solve. Caching is a great answer for most read scaling, but you need to always ask
yourself how many shards does one request touch, and how often. evenly, and look ahead at the consequences, you're in good shape. This is part two, and we've got a lot more on scaling
rights. Follow for the rest, and view the whole scaling rights pattern breakdown on our website, hellointerview.com.