[00:02] 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.
[00:16] 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
[00:31] 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
[00:44] 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
[00:57] 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
[01:11] 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
[01:24] rights. Follow for the rest, and view the whole scaling rights pattern breakdown on our website, hellointerview.com.