System requirements

Functional:

1. to be able to generate unique tiny urls for the given urls
2. users should be able to add custom tiny urls
3. expiry date to delete the old urls
4. allow users to set the expiry date
5. API rate limiter
6. Caching

Non-Functional:

1. Highly available
2. Reliable
3. Redundancy
4. Scalability

Capacity estimation

Let's say we have 1M users.

-> every user let's creates 10 new tiny urls every month

-> every url is 10Kb.

-> so every month we will have 100kb to save for 1 user.

-> for 1M users, 1M * 100kb => 100Gb

read:write => 10:1

so if we create 10 urls for every user in a month, that means 10*1M => 10M writes in total.

and 10*10*1M => 100M reads in total

API design

Write API:

/tinyUrl/post

1. API key
2. user_id
3. org_url
4. custom_tiny_url: optional
5. expiry_date: optional

response: http 200Ok + the tiny_url + message saying that your tiny url has been created.

Read API:

/tinyUrl/get

1. original url
2. user_id

response: tiny_url

Delete API:

/tinyUrl/delete

1. user_id
2. API key
3. org_url

Database design

Users table:

1. user_id: PK
2. orginal_url: string
3. tiny_url: string
4. created_date: datetime

Urls table

1. user_id: PK
2. tiny_url: string
3. original_url: string
4. expiry_date: datetime

High-level design

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?