System Design: From URL Shorteners to Distributed Systems

The Framework

Every system design question follows the same structure:

1. Clarify requirements — Functional and non-functional
2. Estimate scale — QPS, storage, bandwidth
3. Design the API — REST endpoints or RPC contracts
4. Sketch the architecture — High-level components
5. Deep dive — Pick the hardest part and go deep

Example: URL Shortener

Requirements

• Shorten a URL, redirect on access
• 100M new URLs/month, 10:1 read/write ratio
• URLs expire after 5 years

Back-of-Envelope Math

• Write QPS: ~38/s, Read QPS: ~380/s
• Storage: 100M * 12 months * 5 years * 500 bytes = ~300 GB

Key Design Decisions

ID Generation: Use a base62-encoded counter from a distributed ID generator (Snowflake-style). Avoid hash collisions entirely.

Storage: A simple key-value store works. DynamoDB or Cassandra for horizontal scaling. The access pattern is pure point lookups.

Caching: Put a Redis layer in front. URL redirects are highly cacheable — most short URLs follow a power-law distribution where 20% of URLs get 80% of traffic.

The Trade-offs

• Counter vs Hash: Counter is collision-free but predictable. Hash is random but needs collision handling.
• 301 vs 302 redirect: 301 is cached by browsers (less server load), 302 lets you track analytics.

The Meta-Skill

System design isn't about memorizing architectures. It's about reasoning through trade-offs under constraints. Practice by designing systems you use daily — how would you build a simpler version of Twitter, Uber, or Spotify?