System Design Foundations

Why this module exists

Most candidates jump straight to boxes and arrows. Strong designers start with clarity: what success means, what breaks first, and what trade‑offs are allowed. This module is about thinking in constraints before thinking in architecture.

1) Requirements That Actually Matter

Good requirements are measurable:

• Latency: P50 / P95 / P99 targets
• Availability: SLO (e.g., 99.9%)
• Durability: data loss tolerance
• Freshness: how stale is acceptable?

Questions that change the architecture:

• Is the request path read‑heavy or write‑heavy?
• Are we optimizing for global latency or cost?
• What can be eventually consistent?

2) Back‑of‑the‑Envelope Estimation

You don’t need perfect numbers. You need order‑of‑magnitude reasoning:

• Requests/second at peak
• Data size per request
• Storage growth per day/month

Rule: make your math visible. It signals confidence, not guessing.

3) Latency Budgeting

Latency is additive across hops. A strong design has a budget:

• Network: 5–20ms
• Cache: 1–5ms
• DB: 5–50ms
• External service: 50–200ms

If you can’t hit your budget, you redesign the path.

4) Design Philosophy

• Start with the critical path (read or write).
• Minimize coupling (failures should not cascade).
• Make trade‑offs explicit (“We accept staleness to reduce latency”).

Practice Prompts

1. Write requirements for a global notification system.
2. Estimate storage for 10M DAU with 20 messages/day.
3. Sketch a 150ms P99 read path for a social feed.