Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.

Non-Functional Requirements:

• Low latency-> fast redirects
• Scalibility ->handles growth in traffic
• High Availability — system works even if servers fail

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

POST /shorten

{ "longUrl" : "https://..."}

Response: {"shortUrl" : "https://short.ly/abc123"}

Satus :2XX created

GET /{shortID}

Response: 3XX redirect, the header is the long url

STATUS 3XX found or 4XX not found

High-Level Design

Clients -> USERS clicking link

Load balancer -> distributes traffic across servers

Web servers/ App servers - handle request

Cache(like redis) -> store frequently acessed urls for low latency

Database -> stores all url mappings (sql)

Url generator/Id generate -> designs a short unique id

Write path User -> POST/shorten ->load balancer -> web server -> ID generator -> store in DB -> return short url

Read path User ->load balancer -> web server -> check cache -> if miss, check db -> redirect user

Database Design

id(primary key, increment)

short_ket (inique, index)

lond_url (original url)

created_at(time stamp)

SQL, indexed for fast lookups

Hash-based sharding on short_key using consistent hashing"

Writes require strong consistency to avoid duplicate keys; reads can tolerate eventual consistency since a brief delay only risks a transient 404

Detailed Component Design

1. Use a distributed unique ID generator (like a database sequence or Snowflake) to get a unique numeric ID
2. Base62 encode that number (using a-z, A-Z, 0-9) to get a short string like "abc123"
3. That's your short key — guaranteed unique, no collisions
4. The solution is CDN edge caching: cache popular redirects at edge locations worldwide so requests never reach your servers.