Database Scaling
Index it, replicate it, then shard it, in that order and only as far as the numbers force you.
5 lessons · ~52 min · free
By the end you can
- Reach for indexes before architecture, and know their write cost
- Scale reads with replicas and reason about replication lag out loud
- Shard by the right key and spot hot-key skew before it happens
- Choose SQL or NoSQL from access patterns instead of fashion
- Present the escalation ladder (index, cache, replicate, shard) in an interview
Lessons
- 1The database is always the bottleneck10 minRead-heavy vs write-heavy, and why an index is the first move, not a bigger machine.
- 2Read replicas and the lag they bring11 minLeader-follower replication, scaling reads, and the stale read that bites you in the demo.
- 3Splitting the data itself12 minHash vs range partitioning, hot keys, and why resharding is the move you plan for early.
- 4SQL vs NoSQL, minus the tribalism10 minWhat actually differs: schemas, joins, transactions, and scale-out defaults, by access pattern.
- 5The escalation ladder9 minIndex, cache, replicate, shard: the order, the signals for each step, and the traps.
Design with it after
The design library has full system design prompts on a whiteboard canvas with AI feedback. Every one of them gives you a place to apply this.
Open the design library