Storage Case Studies: URL Shortener, Key-Value Store, and File Sync

One startup, three storage problems

Irfan's startup, Chhota, sends SMS marketing campaigns for shops. An SMS holds 160 characters, so every campaign needs short links. That one product leads Irfan into three classic designs, one after another. (Irfan, Chhota and every number here are made up for teaching.)

1. Part A, a URL shortener. Shops need chho.ta/x7Kq2 instead of a 120-character link.
2. Part B, a distributed key-value store. The link table must never be down, even when machines fail, because a dead link in 2 million SMS messages can't be recalled.
3. Part C, file sync. The shops' agencies upload 2 GB campaign videos from laptops on flaky Wi-Fi, edit them and expect every device to stay in sync.

Each one sounds like an afternoon's work, and each hides one hard question:

These designs reuse Caching, Scaling data and Consistency models.

Part A. "Every SMS needs a short link": the URL shortener

Requirements: create a short link for a long URL and redirect quickly. Support an optional custom alias and expiry, and track clicks.

Hypothetical scale:

• 100 million new links per month, about 40 per second.
• Reads outnumber writes 100:1, so about 4,000 redirects per second on average and more at peak.
• Over 5 years that is 6 billion links. At roughly 500 bytes each, about 3 TB.

API: POST /links {long_url, alias?, expires_at?} returns a short URL, and GET /{code} responds with a redirect.

"Two shops got the same code": generating the short code

A 7-character code over 62 characters (a–z, A–Z, 0–9) gives 62^7 ≈ 3.5 trillion combinations, far more than 6 billion. The hard part is handing them out without two servers picking the same one.