Requirements

Functional:

Actor: Visitor

1. Click/visit shortUrl: Should be redirected to originalUrl in < 50 ms via 302 redirect
2. Same shortUrl should always result in same originalUrl
3. [enhancement] can report a shortUrl as unsafe.

Actor: Link creator

1. Link creator can be anonymous (or) known user
2. Submits a originalUrl aka longUrl and gets shortUrl
   1. [optional] can customize shortUrl
   2. [optional] set custom expiration time.
3. Deletes a shortUrl which they have created (if known user)

Actor: Power User

1. [enhancement] Looks into analytics of shortUrls (pertaining to user or group of users)

Actor: System

1. [enhancement] Should prevent maliciousUrl from entering system.
2. [enhancement] Should be able to handle reporting of abusive urls.

-----------------

Non-Functional Requirements:

• High availability (99.9% uptime)
• Low redirect latency ( <100ms p99)
• Horizontally scalable (millions of reads/second)
• Record usage metrics in analytical database, clicks over time, referrers, geolocation, device type etc.,
• Rate limiting per user tier (prevent abuse at scale)

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:

{ "long_url": "https://....." , "custom_alias": "my-link" (optional), "ttl_days": 30 (optional)}

Response (201):

{ "short_url": "http://tinyxyz.com/abc123", "expires_at": "2026-11-11T00:00:00Z" }

POST /report

Request:

{ "short_id": "abc123", "reason": "malware" }

Response:

{ "status": "reported" }

GET /{short_id}

HTTP/1.1 302 Found

Location: https://....

GET /{short_id}/stats

Response 200:

{ "clicks": 1533, "referrers": {...}, "geo": {..}}

High-Level Design

• URL Generator: Handles the post flow , both generating short urls & reporting of urls as well.
• URL Provider: Read service for URL requests, can host caches & other kind of solutions going forward.
• URL Storage: Database where the records of above url stored
• URL evenbus: Capture all database events + url provide redirect events as well.
• URL analytics storage: Listens to eventbus & organize their long term data for further analyssi.
• URL auditor workflow: Verifies reported url is really safe or not, will also look at user who has reported etc., to furether apply any gudielines if needed.
• UserReportin System: Keeps track of user who are generating the urls & capture the consumption capaicity for the user.
• User Usage Metrics: Database system to record user things.
• User Billing system: Billed on usage may be.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.