Back to path
SmallWeekend build ~6h· 4 milestones

Design a URL shortener with real capacity math

The interview classic, done at the depth interviewers actually want. You design a URL shortener and back every choice with numbers, not hand-waving.

API & data modelingCapacity estimationCachingRead/write scalingTrade-off analysisCost modelingObservability basics

What you'll build

A complete design document: API, data model, ID generation, read/write scaling, caching, and back-of-the-envelope capacity estimates with stated trade-offs.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

DESIGN.mdmarkdown
# URL Shortener, Design

## 1. Assumptions
- DAU:
- New links/day (writes):
- Read:write ratio:           # redirects per created link
- Average long-URL length:
- Retention:                  # how long links live

## 2. Capacity Estimates
(see capacity.md, copy the final figures here)
- Peak write QPS:
- Peak read QPS:
- Storage after N years:
- Keyspace required vs available:

## 3. API
(see api.md)

## 4. Data Model
| field      | type        | notes                |
|------------|-------------|----------------------|
| short_code | varchar(8)  | primary key, base62  |
| long_url   | text        |                      |
| created_at | timestamptz |                      |
| expires_at | timestamptz | nullable             |

## 5. ID Generation
- Chosen strategy:
- Collision property:
- Predictability property:
- Rejected alternative + why:

## 6. Read Scaling
- Cache (what it stores, eviction, assumed hit rate):
- Datastore read scaling (replicas / sharding):
- Invalidation / expiry:

## 7. Trade-offs
- 301 vs 302 and why:
- Consistency vs latency:
- Cost driver:

Reading this file

  • ## 1. AssumptionsFill assumptions first because every capacity number you compute later depends directly on these inputs.
  • Read:write ratioThe single most important number for a shortener: it is read-heavy, and this ratio decides the whole scaling plan.
  • short_code varchar(8)The short code is the primary key, the lookup happens billions of times so it must be fast and unique.
  • ## 5. ID GenerationHow you mint codes drives collisions, predictability, and cost, the crux decision of the whole design.
  • ## 7. Trade-offsStating trade-offs out loud is what separates a real design from hand-waving in an interview.

The doc skeleton. Fill it top→bottom; assumptions first because every later number depends on them.

That's 1 of 7 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Scope & estimate

    5 guided steps

    Capacity math is what separates a real design from a vague one. The numbers decide whether you need one box or a sharded fleet, get them first or the rest is guessing.

  2. 2

    Design the core

    5 guided steps

    ID generation is the crux of this problem, collisions, predictability, and coordination cost all hinge on it. Get the core contract and key strategy right and scaling is straightforward.

  3. 3

    Scale the reads

    5 guided steps

    Reads dominate this system, so the read path is where it lives or dies. A caching layer and a read-scaling story are what take your design from “works on one box” to “works at scale”.

  4. 4

    Cost & operability pass

    5 guided steps

    A design that nobody can afford or observe is a thought experiment. Even a weekend build earns senior signal by attaching a real cost number and a minimal health-check plan.

What's inside when you start

3 starter files, ready to clone
4 guided milestones
4 full reference solutions
7 code blocks explained line-by-line
4 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A design doc with diagrams and capacity math
A trade-offs section defending key choices
An ID-generation decision with at least one documented rejected alternative
A one-page cost estimate ($/month and $/million-redirects) and a minimal observability plan

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building