System requirements

Functional:

• URL shortening
• URL redirectoin
• User management
• Link expiration
• Custom url

Non-Functional:

• Availability 99.99
• Performance responding less then 10 milliseconds
• Scalability able to handle increasing traffic without degradtion in performance
• Security: implement measure aginst abusive use, ensuring service is not exploted
• Data integrity: Ensure that URLs are reliably stored and the mapping between short and longURLs remains consistent.

Capacity estimation

• 12,000 requests per minute for creating short URLs.
• 1,200,000 requests per minute for redirecting to long URLs.
• total entry size 144 bytes
• Storage daily 12.4GB
• Long term storage 25 - 30TB

API design

. a post request containing the long url , user id and expiration time and return short url

url_mappings { string short_url "Primary Key" string long_url "URL being shortened" string user_id "Foreign Key referencing users (optional)" date created_time "Timestamp of creation" date expiration_time "Timestamp when the URL expires (optional)" int click_count "Count of redirections (optional)" }

index the short url

High-level design

flowchart TD A[Client] -->|1) Send Long URL| B[API Gateway] B -->|Route Request| C[Shortening Service] C -->|Check Short URL| D[Database] D -->|Exists?| D -->>|Yes| C -->|Return Error| B D -->>|No| C --> |Create Mapping| D C -->|Store Mapping (short_url, long_url, TTL)| D C -->|Update Cache| E[Cache] E -->|Store (short_url, long_url, TTL)| C C -->>|Return short URL| B B -->>|Response (short URL)| A A -->|2) Send Short URL| B B -->|Route to Redirect| F[Redirecting Service] F -->|Check Cache| E E -->|Found?| E -->>|Yes| F -->|Return long_url| B E -->>|No| F -->|Check Database| D D -->>|Found?| D -->>|Yes| F -->>|Return long_url| B D -->>|No| F -->>|Return Error| B B -->>|Final Response| A

Request flows

sequenceDiagram participant C as Client participant AG as API Gateway participant SS as Shortening Service participant DB as Database participant Cache as Cache C->>AG: POST /shorten (long_url, short_url) AG->>SS: Check if short_url exists SS->>DB: Query short_url DB-->>SS: Response (exists or not) alt If exists SS-->>AG: Throw Error else If not exists SS->>DB: Store (short_url, long_url, TTL) DB-->>SS: Success SS->>Cache: Update Cache (short_url, long_url, TTL) Cache-->>SS: Success SS-->>AG: Return short_url end AG-->>C: Response (short_url) C->>AG: GET /redirect/{short_url} AG->>SS: Redirecting Service SS->>Cache: Check Cache alt If found Cache-->>SS: Return long_url SS-->>AG: Return long_url else If not found SS->>DB: Check Database DB-->>SS: Response (long_url or not found) alt If found in DB SS-->>AG: Return long_url else SS-->>AG: Return Error end end AG-->>C: Final Response (long_url or error)

Detailed component design

for database, it can scale by have read replication for reading data and write database for writeing data

for memory database it can scale by sharding

Trade offs/Tech choices

reddis for memory database

mongo for normal database due to it having ttl

Failure scenarios/bottlenecks

long url too long

Future improvements

Need to handle more request and handle ddos and attacker

Have CDN to cache the most used request to reduce latency and handle more request before hitting to main server

Have waf to handle inspect incoming traffic and block malcious request

Have patch management

Have Alert and notification for error or attacker

to handle