Requirements

Functional Requirements:

• The system must create a short URL, no longer than x characters
• The user must be able to specify the maximum number of characters used for the URL
• The user must be able to enter its original URL
• The alias URL must redirect to the original URL

Non-Functional Requirements:

Reliability:

• The link, until deleted or changed, must always redirect to the original url, never somewhere else
• A once created link must never be overwritten by a new link, unless it was deleted

Performance:

• The user must not wait more than 2 seconds for a new short URL

Latency:

• A user must be redirected instantaneously, i.e. not wait longer than 1 second

Scalability:

• The short redirect link must be able to accommodate millions of clicks per day

High availability:

• The link must always be reachable. Highly available means five nines 99.999% uptime

Capacity Estimation

• Daily active users: one million clicks
• Daily new urls: 100
• read/write ratio 10000:1
• daily average read qps:
  • 1000000/86400= 11.57
• daily average write qps:
  • 100/86400=0.0012
• daily qps: 11.57+0.0012=11.5712
• peak qps
  • 11.5712 * 5 = 57.856
• database space requirements
  • pk
  • shorturl: ~20Bytes
  • long url: ~ 580Bytes
  • 600B per row
  • in 1 day: 60KB
  • in 1 year: 21,9MB
• growth: 20% yoy user growth
  • by year 5 reads ~ 29/s avg, peak ~145/s

API Design

get - /{code}

302 - redirect to URL belonging to that code

404 - if that code cannot be found

put- /api/v1/urls/{code}

body - long url

201 - successfully created redirect

200 - if it already existed

409 - conflict when there is already such a url with that short code

response: code and url

post - /api/v1/urls

body - long url

201 - successfully created redirect

response: code andurl

High-Level Design

• web ui
  • to create the links
• reverse proxy for https routing and potential load balancing
• server
  • process the requests
• cache
  • store hot links to not query the database for these
• database
  • store the relation between short link and original url
• service at post route
• service at get route
• id creation service
  • 6 characters long alpahnumeric is enough for 56 billion - apparently feister cipher is good?

Database Design

• SQL Database: classic relational table(s)
  • structured data
  • no heavy write operations
  • need strong transactional guarantee, especially uniqueness
  • only heavy reading
• we have one table:
  • url mapping table
    • shortcode as PK -> unique and index (access is fast due to index)
    • redirect url
    • created at (datetime)

Detailed Component Design

• code generation service
  • cryptographically secure algorithm (standard library) to generate an alphanumeric code of length 6
  • needs uniqueness constraint, check and retry logic if code already found in db
  • any instance can generate - no counter, can scale up generators if needed
  • generation is stateless so there's no single generator to fai
• url repository
  • catch db error, especially uniqueness constraint and throw back to service which can handle new generation and retry
• cache, store a link requested from the db with a ttl of 24 hours
  • makes read operations way faster
  • a single hot code = one shard key, so the cache/CDN absorbs those clicks before they reach the shard
• Single primary DB is enough at this volume; redirects key on code (unique index). If we scale 100×, shard by hash(code) across 100 logical partitions, assigning partitions to physical shards so a redirect routes to exactly one shard — no scatter.
• cache purge on update and delete
• ip throttle and bursts are in reverse proxy