The script
Most SDE2 design rounds are 35–45 minutes. Don't jump to boxes-and-arrows — drive the conversation through these steps and narrate as you go.
- Clarify requirements (5 min). Functional ("what must it do") and non-functional ("how well" — scale, latency, availability, consistency). Write them down. Pin scope: "I'll design X and Y, treat Z as out of scope — agree?"
- Capacity estimation. DAU → QPS, read/write ratio, storage/year, bandwidth. You're justifying later choices (cache? shard? CDN?), not being precise.
- API design. A handful of endpoints (or a sketch of the RPCs). This pins down the contract and surfaces the data you move.
- Data model. Core entities + relationships; pick SQL vs NoSQL with a reason. Call out the access patterns.
- High-level design. Now draw it: clients → LB → services → data stores → async workers. Keep it coarse.
- Deep dive. The interviewer steers you into 1–2 components. This is where the signal is: caching, sharding key, the hot path, a race condition.
- Bottlenecks & trade-offs. SPOFs, hotspots, what breaks at 10×, and how you'd evolve. Close with a crisp summary.
"Highly available" vs "strongly consistent" changes the entire design (CAP). Ask: how many users? read- or write-heavy? is stale data OK for N seconds? what latency? Getting these on the board early earns signal and prevents a wrong turn.
Estimation numbers worth memorizing
| Quantity | Rule of thumb |
|---|---|
| Seconds in a day | ~86,400 ≈ 10⁵ |
| 1M writes/day | ≈ 12 writes/sec average (×~3–5 for peak) |
| Read:write | Most consumer apps are read-heavy (100:1+) |
| L1/L2 cache ref | ~1 ns / ~4 ns |
| Main memory ref | ~100 ns |
| SSD random read | ~16 µs |
| Network round trip (same DC) | ~0.5 ms |
| Disk seek (HDD) | ~10 ms |
| Inter-continental RTT | ~150 ms |
The big takeaway: memory is ~100,000× faster than disk, and a cross-region hop dwarfs everything — which is why we cache and put data near users.
A reusable high-level skeleton
Nearly every design is a variation on this: a CDN for static assets, a load balancer over stateless app servers, a cache in front of the database, read replicas for read scale, and a queue + workers to push slow work off the request path.
Think it through like the interview
The framework only sticks once you've run it. Here it is end to end on the most common warm-up question — try each stage yourself before revealing:
PROBLEMDesign bit.ly: turn long URLs into short ones, redirect short → long. 100M new URLs/month, redirects must be fast, links live for years.
- 1
Step 1–2: Scope, then put numbers on it
“What do I clarify, and what do the numbers tell me before I draw anything?”
- 2
Step 3: API — pin the contract
“Two endpoints. What are they, exactly — and what status code does the redirect use?”
unlocks after the stage above - 3
Step 4: Data model + the key question
“One table — but how do I GENERATE the short code? This is the design's one real problem.”
unlocks after the stage above - 4
Step 5: High-level — draw the skeleton
“Which boxes from the reusable skeleton survive for THIS problem's numbers?”
unlocks after the stage above - 5
Step 6–7: Deep-dive + trade-offs
“Interviewer: 'a celebrity link gets 100K clicks/sec.' And: 'what breaks at 10×?'”
unlocks after the stage above
Design drills
The round itself is a skill. Rehearse the process, not just the systems.
Whiteboard each one out loud for 5–10 minutes before you reveal what a strong answer covers — the gap between your sketch and the checklist is your study list. Progress is saved on this device.
You're asked to 'design a URL shortener'. What do you say in the first 3 minutes, before drawing a single box?
Turn '100M URLs, 100:1 read:write, 10k read QPS' into three concrete architectural decisions.
You've drawn the happy path. What three failure questions should you raise unprompted?
The interviewer says 'now make it global / multi-region.' What changes in your design?