System requirements

Functional:

Client should be able to give a url and create a short URL

Client should be able to specify a custom alias and expiration date for the short URL

Client should be able to redirect to original url using the sort URL

Non-Functional:

System will prioritize availability over consistency (okay with a shortend URL mapping to an old one as long as redirect works)

System should support 1 Billion shorts URLs and 100 million DAU

System should have a latency of (~100ms) creating and redirecting

System should ensure uniqueness long URL mapping to short URL

Capacity estimation

System should support 1 Billion shorts URLs and 100 million DAU

API design

POST {original_url: , expiration_date:, custom_alias:} -> {shortened_url}

GET {short_code} -> {original_url}

Database design

Will have a databse that holds URLs (Postgres) with the following schema AND table of Users

URLS

• original_url
• shortend_url
• expiration_date
• custom_alias
• user_id
• created_at

Users

• id
• email
• First name
• Last name

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. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

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

Write service we can use a counter and base encode 62 it, that can be used as the shortURL, with 1,000,000,000 -> a 6 char string

Can include a cache for read Service

• we can have it be LRU, this way if we hit capacity we can get ride of the least used one
• key: short_url
• value: long_url

Trade offs/Tech choices

Security wise, people can figure out its a counter

Failure scenarios/bottlenecks

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

Future improvements

Ensuring uniqueness in short URLS

Ensure read/write throughput (we will have more reads than writes)