System requirements

Functional:

The system should take a full length URL and return a tiny url.

The system should handle a large amount of request.

The system should have high availability and should not go down.

The tiny URL should be randomlized and not guessable.

One full length URL can have multiple tiny URLs.

Users should be able to check what URLs they have converted.

Users can delete tiny URLs they generated.

Implement traffic meter for each user.

Non-Functional:

The pricing of the service.

The frontend control page for the URLs.

Capacity estimation

Traffic:

The system is expected to serve 10 million users, who are going to access the tiny url 100 times per day.

In total, thats 1 billion request per day.

If the requets are spreaded evenly, then on average, thats 1 billion/86400 seconds = 11k QPS.

If the peak is 5X the average, then we need to design a system that can handle 50k QPS.

Storage:

If 100k tiny URLs are created everyday,

API design

Define what APIs are expected from the system...

Database design

URL table:

id: double

original_url: string

tiny_url: string

created_at: timestamp

updated_at: timstamp

deleted_at: timestamp

user_id: string

rate_plan: RatePlan

RatePlan table:

id: double

plan_type: enum

plan_rate: int

created_at: timestamp

Rate table:

id:double

url_id: double

requets_count_hour

Request Table (use data streaming table such as Snowflake, Kafka. This is for Audit usage)

Request user_id, ip, timestamp, type, url_id,

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your 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?