System Design Studio
Deep architectural breakdowns: functional scopes, capacity planning, distributed caching, database indexing, and scaling trade-offs.
Design a High-Throughput URL Shortener (TinyURL)
Functional Requirements
- Given a long URL, return a unique 7-character short URL.
- Accessing the short URL redirects the client via HTTP 301/302.
- Custom alias support and link expiration dates.
Non-Functional Requirements
- High read-to-write ratio (100:1 read heavy).
- Ultra-low latency (<10ms for redirects).
- High availability (99.99%).
High-Level Architecture
DNS -> CDN / Edge -> Load Balancers -> Shortener API Gateway -> Redis Read Cache -> Distributed SQL/NoSQL Database (Turso/Postgres/Cassandra) with a distributed token range generator or Snowflake ID generator.
Capacity Assumptions: 100M writes/month ≈ 40 writes/sec. 10B reads/month ≈ 4,000 reads/sec (peak 10,000 reads/sec). 7 chars Base62 = 62^7 ≈ 3.5 trillion URLs.
Core System Components (4)
Validates long URL, generates Base62 alias, persists to database and cache.
Pre-generates unique 64-bit IDs without DB collisions.
Stores Top 20% most accessed URLs (Pareto principle).
Stores mapping: id, short_key, long_url, user_id, created_at, expires_at.
Bottlenecks & Trade-Offs
Key Engineering Takeaways
- Separate ID generation from encoding to guarantee zero collision handling overhead.
- Caching hot redirects eliminates 99% of read queries from hitting persistent disk.