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.

1. Clarify requirements (5–8 min): functional vs non-functional, MVP scope, constraints
2. Back-of-envelope estimation (3–5 min): DAU, QPS, storage, bandwidth
3. API & data model sketch (5 min): core endpoints and entities
4. High-level design (10 min): boxes and arrows for the hot path
5. Deep dives (15–20 min): interviewer picks 2–3 areas
6. Wrap-up (3–5 min): failure modes, monitoring, 10× scale

Estimation anchors every design decision. Round aggressively to powers of 10. State assumptions loudly. Interviewers evaluate reasoning, not arithmetic precision.

• 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)

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.

• 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

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.

1. State the constraint ('p99 < 100ms for feed load')
2. Name 2 options with pros/cons
3. Pick one and justify for THIS product's requirements
4. Acknowledge when you'd revisit ('at 1B users, shard by user_id')

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.

• 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