Layer 3 · Go deeper · 9 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Back of the envelope
Size it up
Tap through each step of the arithmetic.
How many inserts a second when indexes don’t fit in memory?
Does a 10-million-a-day UPI-style payments service fit on one primary?
Build-up · 6 steps
Climb the ladder, rung by rung
Each rung answers one kind of bottleneck, and each is harder to build and undo than the one below it.
Step 1 of 6
Measure first
Every rung fixes one kind of saturation, so first find what runs out at peak, CPU, memory, I/O, locks, connections, lag or storage, and which query shapes cause it.
4 interview moments
You’re the candidate
The interviewer pushes on the hard parts. Pick an approach and see how it holds up.
Deep dive 1 of 4
Interviewer
“At peak, the app tier autoscales from 20 to 200 pods. The database starts refusing connections. What do you do?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“The primary sits at 90% CPU at peak, and most of it is reads. What do you do?”
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“Writes, not reads, now saturate the primary. What’s your plan?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“One domain’s writes will outgrow the biggest primary within a year, and you need strongly consistent writes across regions. How do you scale it?”
The team doesn’t want to own a sharding layer.
Your move. Pick an approach:
Build-up · 5 steps
Pick the next rung from a measurement
Start from what saturates at peak. Ask about query cost and connections before anything structural, then split the problem into reads and writes.
Step 1 of 5
Start from the bottleneck
Start from the measured bottleneck, not a favourite technology. Each leaf names the rung to try first, not the last one you will ever need.