Chapter
Design Interview Skills
How to drive a full interview from requirements through scaled architecture.
Full Interview Flow
Strong candidates narrate tradeoffs continuously. Weak candidates jump to microservices without clarifying scale. A structured 45-minute flow ensures you cover requirements, estimation, design, deep dives, and wrap-up without running out of time.
- Clarify requirements (5–8 min): functional vs non-functional, MVP scope, constraints
- Back-of-envelope estimation (3–5 min): DAU, QPS, storage, bandwidth
- API & data model sketch (5 min): core endpoints and entities
- High-level design (10 min): boxes and arrows for the hot path
- Deep dives (15–20 min): interviewer picks 2–3 areas
- Wrap-up (3–5 min): failure modes, monitoring, 10× scale
Communication habits
Repeat requirements back. State assumptions explicitly ('100M DAU, 10:1 read/write'). Think aloud. Ask 'Should I go deeper on X or Y?' when time is tight.
Common pitfalls
Naming Kafka/Redis without justification. Ignoring the read/write ratio. No numbers. Forgetting failure modes. Designing for Google scale when interviewer said 10K users.
Capacity Estimation Worked Examples
Estimation anchors every design decision. Round aggressively to powers of 10. State assumptions loudly. Interviewers evaluate reasoning, not arithmetic precision.
| Assumption | Calculation | Result |
|---|---|---|
| 100M MAU, 20% DAU | 20M active/day | ≈ 2×10⁷ DAU |
| 5 actions/user/day | 20M × 5 / 86,400 sec | ≈ 1,200 QPS avg |
| Peak 3× average | 1,200 × 3 | ≈ 3,600 QPS peak |
| 500 KB avg photo, 10M uploads/day | 10M × 500 KB | ≈ 5 TB/day new storage |
| 1 year retention, 3× replication | 5 TB × 365 × 3 | ≈ 5 PB (round to 5 PB) |
- 1 day ≈ 10⁵ seconds (86,400); 1 month ≈ 2.5×10⁶ sec; 1 year ≈ 3.15×10⁷ sec
- 1 KB → 1 MB → 1 GB → 1 TB: know powers of 2 and 10
- Bandwidth = QPS × payload size; watch egress cost at scale
- Memory estimate: cache hot data (top 20% keys = 80% traffic)
Twitter back-of-envelope
300M MAU, 150M DAU, 2 tweets/day → 300M tweets/day → ~3,500 write QPS. Timeline reads dominate — 10:1 read/write → ~35K read QPS. Fan-out on write for normal users.
Sanity check
After calculating, ask: 'Does 3,600 QPS need sharding?' Probably not — a few app servers + one DB with cache handles it. 'Does 5 PB need object storage?' Yes — S3/GCS, not a single Postgres.
API Design Best Practices
API design bridges clients and backend services. In system design interviews, listing core endpoints demonstrates you think about the contract, not just infrastructure boxes. Prefer REST for CRUD; consider GraphQL for flexible client queries; gRPC for internal service-to-service.
| Method | Endpoint | Purpose |
|---|---|---|
| POST | /v1/orders | Create order (idempotency key header) |
| GET | /v1/orders/{id} | Fetch order by ID |
| GET | /v1/users/{id}/feed?cursor=X&limit=20 | Paginated feed (cursor-based) |
| PUT | /v1/users/{id}/profile | Update profile (idempotent) |
| DELETE | /v1/sessions/{id} | Logout / revoke session |
- Version in URL (/v1/) or header — plan for breaking changes
- Cursor-based pagination for infinite scroll (not offset for large tables)
- Rate limit headers: X-RateLimit-Remaining, Retry-After
- Consistent error format: { code, message, request_id }
- Use nouns for resources, verbs via HTTP methods
Pagination deep dive
Offset pagination (page=100) degrades on large tables — DB scans skipped rows. Cursor pagination uses indexed timestamp/ID: WHERE id < cursor LIMIT 20. Stable under concurrent inserts.
Tradeoff Communication
System design interviews test judgment, not memorization. Every decision has a tradeoff — articulate alternatives considered, why you chose one, and what you'd change at 10× scale. This is what separates senior from junior signals.
| Decision | Option A | Option B | How to frame |
|---|---|---|---|
| Feed generation | Fan-out on write | Fan-out on read | Write amp vs read latency; hybrid for celebrities |
| Database | PostgreSQL | Cassandra | ACID + joins vs write scale + AP |
| Cache | Redis cluster | Local cache | Consistency vs latency; two-tier for hot keys |
| Sync vs async | Sync API call | Queue + poll/webhook | User waits vs complexity + eventual result |
| Consistency | Strong (CP) | Eventual (AP) | Correctness vs availability during partition |
- State the constraint ('p99 < 100ms for feed load')
- Name 2 options with pros/cons
- Pick one and justify for THIS product's requirements
- Acknowledge when you'd revisit ('at 1B users, shard by user_id')
Magic phrase
'Given [requirement], I'd choose X because Y. The tradeoff is Z, which we mitigate by [strategy].' Use this structure for every major decision.
Security & Privacy Basics
Security is a standard wrap-up topic. You don't need to design a full zero-trust architecture — cover authentication, authorization, encryption in transit/at rest, input validation, and privacy basics for the data you're storing.
| Area | Practice | Interview mention |
|---|---|---|
| Authentication | OAuth 2.0 / JWT / session tokens | Short-lived access + refresh tokens |
| Authorization | RBAC / ABAC per resource | Check ownership on every mutation |
| Transport | TLS everywhere (HTTPS, mTLS internal) | Terminate at LB; cert rotation |
| At rest | AES-256 encryption, KMS-managed keys | Encrypt PII columns or full disk |
| Input | Validate, sanitize, parameterized queries | Prevent SQL injection, XSS |
| Privacy | GDPR/CCPA: delete, export, consent | PII minimization, retention policies |
- Rate limiting and CAPTCHA against brute force and abuse
- Signed URLs for time-limited access to private object storage
- Audit log for sensitive operations (admin actions, data export)
- Secrets in vault/KMS — never in source code or env files in repo
Don't over-engineer
Mention security in wrap-up unless the problem is security-focused (design auth system). 2–3 minutes: HTTPS, auth, encryption at rest for PII, rate limiting.