What this prompt does
This prompt asks the AI to design a Bitly-style URL shortener from first principles, sized to your traffic. You feed it [daily_urls] and [daily_redirects], and it works through ten areas: high-level architecture, the shortening algorithm, database choice and schema, a caching layer, read/write optimization, analytics, custom aliases, expiration, abuse prevention, and a scaling plan up to [target_scale].
The structure works because a URL shortener looks trivial until the numbers force tradeoffs. By passing [daily_redirects], you push the model to treat the redirect path as the read-heavy hot path it really is, which drives the caching design. The [hash_strategy] variable decides whether you get Base62-with-counter, hashing, or KGS-style key generation, and [cache_strategy] shapes the hot-URL layer. Grounding everything in capacity estimation keeps the answer honest about storage, bandwidth, and QPS rather than hand-wavy.
When to use it
- You're prepping for a system design interview and want a structured URL-shortener walkthrough
- You're actually building a link service and need to reason about the read-heavy redirect path
- You want to compare
[hash_strategy]options before committing to key generation - You need capacity math for storage, bandwidth, and QPS at
[target_scale] - You're deciding between a write-optimized and read-optimized database schema
- You want a defensible plan for caching, custom aliases, and collision handling
Example output
Expect a long-form design document: an architecture description (often with an ASCII or described diagram), the encoding algorithm with collision handling, a database schema, a caching section keyed to your [cache_strategy], capacity estimates with actual numbers derived from [daily_urls] and [daily_redirects], and a staged scaling narrative from one server to [target_scale]. It reads like an interview answer or an internal design RFC.
Pro tips
- Set
[daily_redirects]realistically — the read/write ratio it implies is the single biggest driver of the whole design - Try the prompt twice with different
[hash_strategy]values to see the tradeoffs between counter-based Base62 and hashing - If you care about analytics, ask it to expand step 6; click, geo, and referrer tracking is easy to under-specify
- Push it to show the capacity math, not just the conclusion — that's where interview answers and real plans earn trust
- For
[target_scale], give a concrete number; "web scale" produces vague answers, "10 billion URLs" produces sharding decisions - Treat the database recommendation as a starting point and ask it to justify the choice against your write-vs-read profile
