1Context and scope
Users create short links and millions follow them. A redirect looks up the short code and returns the long URL. Most traffic is redirects, and a few links are far more popular than the rest.
2Goals and non-goals
Goals
- 4,000 requests a second: 95% redirects, 5% new links.
- Success at least 99.9%, p99 at most 100 ms, cost at most $1,500 a month.
Non-goals
- Click analytics dashboards and custom vanity domains.
- Editing or deleting a link after it is created.
- Codes that cannot be guessed (use a random code and abuse checks if that matters).
3Capacity estimate
Back-of-the-envelope numbers from the template. The simulation uses the same ones, so you can check them against a run.
| Quantity | Value | How |
|---|---|---|
| Redirects | 3,800/s | |
| Misses to the store | ≈ 760/s | at the cache’s 80% hit rate |
| Store capacity | 1,600 ops/s | 4 partitions × 400 ops/s each |
| Popularity | Zipf 1.2 over 100,000 keys | the top links get a large share of all reads |
4The design
Each component in the template, in the order a request meets it, and why it is there.
- Load balancer and API
Stateless redirect and create endpoints.
- Redis cache
Keeps hot short codes in memory; the redirect path is the one to optimise.
- Key-value store (4 partitions)
Source of truth for code → URL. Keys are spread over partitions by hash; each partition has its own throughput limit.
5Key concepts
Average load is not partition load
Hashing spreads keys evenly, not traffic. If one key gets 20% of reads, its partition gets at least 20% of the load no matter how many partitions you add. That partition throttles while the others are idle.
Hot keys
Viral links are the classic hot key. Fixes target the key itself: cache it (it will hit almost always), replicate it, or add a random suffix to spread copies across partitions.
Read/write ratio drives design
With 95% reads, the read path is everything: cache, CDN, and a store optimised for point lookups. Writes need unique short codes, often pre-generated so creation never waits.
6Alternatives considered
- More partitions add capacity and cost but do not fix a single hot key.
- A higher cache hit rate is the cheapest fix for skewed reads.
7Failure modes and fixes
What goes wrong in the simulation, why, and the change that fixes it. Each one shows up as a finding in the lab; ask “what broke?” to see it, and for the fix when you want it.
The hottest partition throttles while the average looks fine.
WhyZipf popularity sends a large share of misses to one partition, which hits its 400 ops/s limit.
FixRaise the cache hit rate (hot keys cache well), add partitions, or spread hot keys; check the cost budget as you go.
8Try it in the lab
Open the template, then type these into the copilot one at a time. The first few are also offered as buttons when the template opens.
cache hit rate 95%Far fewer misses reach the store; the hot partition cools.
double the partitionsMore capacity overall; compare the hottest partition before and after.
traffic spike 3xWatch which partition gives way first.
how much does it costCheck the monthly cost against the $1,500 budget.
9Check yourself
- Why does adding partitions not fix a single viral link?
- What is the cheapest way to protect the store from hot keys?
- How would you generate unique short codes without checking for collisions on every write?