System requirements

Functional:

• anonymous users create shortened URL from a user-provided
• users visiting the shortened URL will be redirected the fully qualified URL
• no update, no deletion

Non-Functional:

• highly available, n 9s
• eventual consistent -- uploaded URL will eventually be visible
• 
  

Capacity estimation

• 10M DAU, average 10 shorten request per day --> 10M * 10 / ~100K = 1KQPS
• 1B click through shortened URL --> 1B / ~100K --> 10K QPS on average, peak might be magnitude more
• URL < 1KB, 10M * 10 * 1KB --> 100GB/day

API design

POST /api/v1/shortenURL

GET /api/v1/redirect

Database design

Do not need transactions/ACID. loose relations. Use NoSQL/KV store

Schema:

Key will be the shortened URL

Value will be

• fully qualified URL
• creation time
• time to live

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?