Base62 Key Space Lab (Interactive)
Size the 62^k key space by length, then replay a click burst through cache tiers. Compare a base62 key-space ceiling and range-counter versus hashed allocation while cached lookups absorb a hot click replay.
TinyURL / Bitly: Base62 Keys, Ranges & Redirect Economics
Issue short keys from a range-based counter or truncated hash, then replay 1,000 clicks through a Redis cache tier.
Capacity 62^7 = 3,521,614,606,208 keys
Hot 20% of URLs serve 80% of the ~4,000 reads/sec traffic
Click "Shorten URL" — counters embed ID #1,000,001 as Base62; MD5 buckets may repeat keys with an -r retry suffix (DB roundtrip).
HTTP 301 lets browsers cache the redirect forever (server load collapses, click analytics die); HTTP 302 makes every click hit the Redirect Service so the Kafka analytics topic records geolocation and referrer. Sequential counters are guessable — production systems shuffle the Base62 alphabet or run the ID through a Feistel permutation before encoding.
How It Works Under the Hood
A shortener trades slug length against key-space ceiling: a 7-character base62 code holds 62^7 (about 3.5 trillion) URLs, so length is capacity you cannot take back. Allocation strategy matters just as much — a monotonic range counter yields dense, enumerable IDs while a hashed counter scatters them. Because reads dominate writes by a thousand to one, a hot click burst is a cache problem more than a storage problem, and the hit ratio decides how many lookups ever reach the database.
Core Architectural Principles
- Key space is exactly 62^length, so 5 chars fit 916 million slugs and 8 chars over 200 trillion.
- A range counter mints dense, guessable IDs; hashing the counter scatters them to hide the next ID.
- Read-heavy click replay: only (1 - hit ratio) of lookups miss the cache and hit the datastore.
Start with the read/write skew — shorteners are read-dominated, so the cache hit ratio, not the database, sets your latency and scale. Then justify slug length from the key-space math and pick an allocation strategy, counter versus hashed, explicitly while weighing enumeration risk. Naming 62^k capacity per length signals real back-of-envelope fluency.
Dense counter IDs are compact and cache-friendly but guessable, while hashed IDs hide the sequence at the cost of collisions and re-tries.