Design URL Shortener: System Design & Architecture

Scope

Back-of-the-Envelope Estimates

• Assume 10M MAU, 1M DAU; 90% reads (redirects), 10% writes (shorten).
• Write volume: 1M DAU creating ~0.5 links/day each = ~550k new URLs/day = ~6 writes/sec average. Applying a 10x peak factor gives ~60 writes/sec at peak. The derivation chain is: DAU x links-per-user-per-day, divided by 86,400 seconds (number of seconds in a day), times a peak multiplier.
• Read volume: a 90/10 read/write split means 9 reads for every 1 write, so we take the ~6 writes/sec average from the line above and multiply by 9 = ~54 reads/sec average. Applying the same 10x peak factor gives ~540 reads/sec at peak. This is why the read (redirect) path is the one we optimize hardest.
• Storage requirements: ~550k URLs/day x 365 days = ~200M URLs/year (retention is 1 year). At ~200 bytes per mapping (short code + long URL + metadata) that is ~40GB of raw data. The ~200 bytes breaks down roughly as the long URL (~100 bytes, the dominant cost), the 6-byte short code, two 8-byte timestamps (created_at, expires_at), all rounded up to a clean ~200; multiply by 200M rows (200M x 200 bytes = ~40GB). The key takeaway is that 40GB is tiny: it fits comfortably on a single modern node, so the database decision is driven by access pattern (fast key-value lookups at high read throughput) rather than by raw capacity, which is why a key-value store plus a cache is sufficient and heavy sharding for volume alone is unnecessary.
• Short code length: 6 characters with base62 encoding (0-9, a-z, A-Z) gives 62^6 = ~56.8 billion combinations. Against our ~200M URLs that is ~280x headroom, so collisions are vanishingly rare and a longer code is unnecessary.

Data Model & Storage

• URL Mapping DB (DynamoDB NoSQL): short_code → { long_url, created_at, expires_at }
• Cache Layer (Redis): Hot short_code → long_url mappings for fast redirects
• Expiration Index (DynamoDB GSI): A secondary index on the NoSQL database organized by expiration date to efficiently find and delete expired URLs without scanning the entire database

API Design

Low-level Design

• Short code generation (primary: counter-based): an atomic counter produces a unique integer per URL, which we base62-encode into the short code. Unique by construction, so no collision handling is needed.
• Base62 encoding: Uses URL-safe characters (a-z, A-Z, 0-9) giving 26 + 26 + 10 = 62 possible characters per position. For a 6-character code, this provides 62^6 = ~56.8 billion unique combinations.
• Counter weakness - predictability: sequential IDs make codes guessable/enumerable (anyone can scan every URL). Mitigate by encoding through a bijective scramble or adding a large random offset so codes are not sequential.
• Expiration handling: TTL set to 1 year (365 days) from creation timestamp.
• Cache strategy: cache-aside on read with TTL-based invalidation. Optionally write-through on create, but only if you assume links are shared and clicked immediately; otherwise write-through pollutes the cache with cold entries that may never be read.

DB Schemas

- URL Mapping DB (DynamoDB/MongoDB)
  Key: short_code
  Fields: { long_url, created_at, expires_at }

- Cache Layer (Redis)
  Key: short_code -> long_url
  TTL: 1 hour (repopulated on next read after TTL expiry)

- Expiration Index (DynamoDB GSI)
  Partition Key: expires_at (day) → e.g. "2025-10-09"
  Sort Key: short_code → e.g. "a1b2c3"
  
  Query: GSI where expires_at_day = '2025-10-09'
  Returns: All short codes expiring today
  
  Without this GSI, you'd have to scan the whole table to find expired items (terrible at scale).
  With this index, you can just pull "today's bucket" and clean those up.

{
  "long_url": "https://example.com/very/long/path"
}

{
  "short_code": "aB93xY",
  "short_url": "https://short.ly/aB93xY",
  "expires_at": "2027-06-15T10:30:00Z"
}

GET /aB93xY HTTP/1.1
Host: short.ly

HTTP/1.1 302 Found
Location: https://example.com/very/long/path

# 404 if the code is unknown or expired:
HTTP/1.1 404 Not Found

Concluding Discussion

Critical Knowledge