Requirements

Functional Requirements:

• create(longUrl) -> shortUrl
• visit(shortUrl) -> 302 redirect -> longUrl
• delete(shortUrl) -> by creator

QQ: can anonymous user create shortUrls

Fast follows:

• Tiers of user , 100 urls per day creation.
• Analytics etc.,

Non-Functional Requirements:

• Availability:
  • visit needs to redirect with high availability
  • create also needs to have high availability but visit is high precedence
• Latency
  • Redirect should be triggered in 50 ms

Capacity Estimation

Active Users: 200M

Traffic:

URLs created per user per day: 10 -> 2B writes/day -> 2B/86,400 -> 1/43 Million -> ~20K TPS

URL redirects per day: assume each short url is accessed on an avg 100 times. 100:1 read to write ration

URL redirects: 100 * 20 K ~= 2M TPS

At 10x peak = ~200k writes, 20M TPS reads

Storage:

• short_key + long url + timestamp (created) + timestamp(expired) + userid (optional may be)
  • [62 chars + 2048 chars + 24 chars + 24 chars + 64 chars] ~= 2500 chars = 5000 bytes = 5kb (worst case)
• 2B creation per day = 2 * 5 kb ~= 10 TB per day, per month 300TB, per year 4PB.

 Realistically, average long URL is ~200 chars and most users create <1 URL/day, bringing storage to ~10-100 GB/day." , per year 4TB-400TB.

API Design

POST /shorten

Request:

• longUrl : www.example.com/abc/....
• [optiona] validity: 3 # in days, by default 365 if not mentioned
• [optional] shortCode: 7 chars or 8 char (62 ^7 combinations.. if it exist will be given)

Response: [201 - created]

• shortCode {7 chars}

GET /{shortCode}

Response: [302 - redirect]

• longUrl

High-Level Design

Entry Layer: A Load Balancer distributes incoming traffic across multiple API Gateway instances. The API Gateway handles SSL termination, rate limiting (e.g., 100 req/s per IP), request validation, and routes requests to the appropriate service (POST /shorten → Write Service, GET /{id} → Read Service).

CDN: Visitors hitting GET /{shortId} are routed through a CDN. If the mapping (shortId → longUrl) is cached at the CDN edge, the CDN serves a 302 redirect directly. On cache miss, it forwards to the API Gateway.

Write Path (Create a short URL):

1. Creator sends POST /shorten with { "long_url": "...", "custom_alias?": "...", "ttl_days?": "..." }
2. URL Write Service generates a unique shortId (e.g., Base62 encoding of a Snowflake-style distributed counter) so no DB check is needed
3. Write Service publishes the record to a Message Queue for durability
4. A Batching Service consumes from the queue and writes batches to Redis (write-through cache) and DynamoDB (persistent store)
5. Write Service immediately returns the short URL to the creator

Read Path (Redirect to long URL):

1. Visitor clicks short URL → CDN → API Gateway → URL Read Service
2. Read Service checks Redis cache — if found, returns 302 redirect immediately (~1-5ms)
3. On cache miss, Read Service queries DynamoDB (key: shortId → value: longUrl), populates Redis with a TTL, and returns 302 redirect

Storage Layer:

• Redis: Write-through cache with TTL (e.g., 24h or matching URL expiration). Serves 99%+ of reads without hitting DB.
• DynamoDB: Persistent key-value store. Primary key = shortId. Stores longUrl, userId, creation timestamp, expiration, and click count. Fast point-lookups for cache misses.

Database Design

Table - URLShortener

shortId: partitionKey

longUrl: string (GSI - hashkey)

timestamp: datetime

ttl: long

userId: string (GSI - sortkey)

Writes use strong consistency, reads use eventual consistency.

Detailed Component Design

URL Write Service: Generates a base62 range based partitioned key generation. This is used in message q to do strong consistent batch commit to dynamdb.

URL Read service: reads from redis cache to dyanmdb.

CDN: Viral shortUrls are handled by CDN and through cache protecting the datbase