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. Viral Link / CDN Edge Caching For extremely popular short URLs (e.g., a link shared millions of times), replicate redirects to a CDN edge cache (like CloudFront or Cloudflare). The CDN serves 302 redirects directly from edge locations worldwide, bypassing application servers and Redis entirely. The TTL can be short (e.g., 60 seconds) or long for permanent links, with cache invalidation if the target URL changes.