Designing an App End-to-End

System design isn't a puzzle with a right answer — it's a conversation about trade-offs. The framework that works: clarify requirements, estimate scale, sketch the high-level shape, then drill into the hard parts.

The framework

1. Requirements — functional (what does it do) and non-functional (how fast, how many users, how durable). "Design a URL shortener" is meaningless until you know if it's for 100 users or 100M.
2. Back-of-envelope — QPS, storage, bandwidth. 1M users × 10 req/day = ~120 QPS — suddenly "needs to scale" is a number.
3. High-level shape — boxes and arrows: API → service → DB → cache. Don't optimize yet.
4. Drill the hard parts — where does it break? What's the bottleneck? What happens when the DB dies?

Walkthrough: URL shortener

Requirements: short link → redirect, custom aliases, analytics. Scale: 100M URLs, 10:1 read:write.

• Storage: urls table (id, slug, long_url, user_id, created_at) — small rows, Postgres handles it.
• Redirect: GET /{slug} → cache lookup → DB fallback → 301. Reads are cache-heavy; writes are rare.
• ID generation: base-62 encoding of an auto-increment — or a hash; collision handling needed either way.
• Analytics: async (queue the click event, write to a clickstream store), not in the redirect path.

Walkthrough: a feed

Fan-out problem: when a user posts, push to every follower's feed (fan-out on write — read is cheap, write is expensive for high-follower users) or pull on read (fan-out on read — write cheap, read expensive). The answer for most social systems is hybrid: fan-out on write for normal users, pull on read for celebrities (avoids writing 10M feed rows for one post).

Field notes

• The deliverable is the trade-off discussion, not the diagram — "I'd shard by user_id because reads dominate" is the sentence that matters.
• Every component you draw needs a failure story: what happens when it dies? If you can't say, you don't understand the design.