System requirements

Functional:

1. Given long url return a short url
2. Short url should have an expiration date
3. Short url is associated with the user id
4. Given a short url return the associated long url

Non-Functional:

List non-functional requirements for the system...

1. Service is always available
2. Eventual consistency is import

Capacity estimation

API design

Request:POST /api/v1/shorturl

{ expiration_date, longurl}

Response: { shorturl, expiration_date}

PATCH /api/v1/{shorturl}/

{ timestamp, expiration_date, longurl}

Response: { shorturl, expiration_date }

DELETE /api/{tinurl}

Repsonse: Status

GET /api/v1/url/{short_url}

Response: { timestamp, expiration_date, longurl}

Database design

User Table: userid

Url Table: userid, timestamp, expiration date, long_url, short_url

High-level design

Create Tiny URL

Client -> Load Balance -> API Gateway -> URL Generation Service -> Message Queue -> Database

Request Tiny URL

Client -> Load Balance -> API Gateway -> URL Request Service -> Cache -> Database

Future:

URL Request Service -> Message Queue -> Logging Service -> Database

Request flows

Tiny URL creation flow

1. Client request hits the load balancer with a long URL
2. load balance talks to API gateway for rate limiting, security
3. Gateway talks to URL generation service
4. URL Generation Service generates the tiny URL and returns to the client
5. The Generation service also puts the tiny URL on the message queue
6. The Short URL Processer reads the short URL message queue and stores it in the database

Tiny URL creation flow

1. Client request hits the load balancer with a long URL
2. load balance talks to API gateway for rate limiting, security
3. Gateway talks to URL Request service
4. The URL Request service reads checks the cache
5. If not in the cache it reads from database and writes to cache and returns short URL to the client

Detailed component design

Generate URL

Short Url CreateUrl(timestamp, server, user id)

• Generate a Random URL based on (Server, Timestamp, User Id)
• Check to make sure the URL does not exist

Request URL

Get URL(URL)

• Check URL in cache
• If not in cache check database
• Write to cache if does not exist

Trade offs/Tech choices

Used Cache for Frequently requested URLs

Load balance to distribute load

API Gateway for logging, security, rate limiting

NoSQL database

Eventual consistency if fine

Message queue - pub/sub for later writes to database

Failure scenarios/bottlenecks

Database is important

The cache can go down but the database cannot

Future improvements

It also puts a message on the message queue for logging access statistics