System requirements

Functional:

• Shorten URL
• Redirect
• Analytics
• Custom Alias
• User Accounts
• Expiration
• API Access
• Security
• User permissions: Different user tiers that may affect URL creation limits, custom domains, or access to analytics data.
• URL Management: Options for users to view, edit, or delete their short URLs.
• Mobile Access: Considering mobile optimization in the design can enhance usability.

Non-Functional:

• Scalability
• Performance
• Reliability
• Security
• Data consistency
• Maintainability
• Usability
• Cost-effectiveness

Capacity estimation

• Users: 100k
• 10 mil URLS
• %10 users active/day (10k)
• active user creates 10 URLS (100k) created/day
• active user clicks 5 URLS (50k) used/day
• Create URL
  • Bandwidth
• structure:
  • full URL: 100 = 100 bytes
  • short URL: 22 = 22 bytes
  • Date Created: 8 bytes
  • Expiration Date: 8 bytes
  • Times Used: 10 bytes = 2 ^ 80
  • Date Last Used: 8 bytes
  • UserID: 36 bytes
  • Custom Alias: 20 = 20 bytes
  • Referrer URL: 100 bytes

Storage: 456 bytes

• full URL: 100 bytes
• short URL: 10 bytes
• username: 100 bytes
• password: 100 bytes
• createdDate: 8 bytes
• expirationDate: 8 bytes
• customShortURL: 10 bytes
• referer: 100 bytes
• times used: 8 bytes; 2^8*8
• 30 mil urls a month = 30mil * 456 = 13680000000 bytes
• 13.680 Gb/month
• 13.680 * 12 * 5 = 820 GB 5 years

Bandwidth: 1160 Bytes/second

• Create = 666 * 100000/24/60/60 = 770.83
• Use (658 * 50000) / 24/60/60 = 380.79 bytes/second

API design

Rest API

• Create ShortURL
  • POST
  • myDomain/myShortURL
  • Header
    • UserID: 36 bytes
  • Request
    • full URL: 100 bytes
    • customURL: 100 bytes
  • Response
    • short URL: 22 bytes
    • Expiration Date: 8 bytes
  • Size: 400 + 266 = 666

• Use ShortURL
  • GET
  • myDomain/myShortURL
  • Header
    • UserID: 36 bytes
  • Request
    • short URL: 22 bytes
    • customURL: 100 bytes
  • Response
    • full URL: 100 bytes
  • Size 400b + 258 = 658

Database design

Use a NoSQL (dynamo DB) table for flexibility and performance. We don't need a SQL (RDS) database because we don't have complex queries or joins to perform

URL Table

• shortURL
• longURL
• UserID
• userCount
• createdDate
• expirationDate
• customAlias
• RefererID

Referer Table

• RefererID
• Referer URL

User Table

• UserID
• UserName
• HashedPassword Argon2
• salt

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

Create short URL Flow

1. Login
2. Enter in long URL
3. Enter in custom short URL(if wanted)
4. Hit Submit
5. Short URL, UserID are sent to the system
6. a short URL is generated and given to the user

User a short URL Flow

1. Short URL is clicked on
2. Short URL is sent to the system
3. Check Expiration
4. Update use count
5. Long URL is returned

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...

How do we scale up?

Servers/DB

• horizontal scaling
  • fault tolerance
  • performance

Authentication

• SSO with OAuth2.0
• UserID
• Password
  • requirements
  • hash password + randomSalt + pepper (Argon2)
• MFA

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.

• Database overload
• Network latency
• Link collision
• outage
• secure links generated
• duplicate custom aliases
• bad UI

Future improvements

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

• Database overload
  • Split databases up with sharding to reduce load
  • Caching commonly used urls
• Network latency
  • multiple servers
  • DB sharding
  • caching
• Link collision
  • adding part of unique userids to prevent collision
• outage
  • we have high fault tolerance through redundancy
• secure links generated
• duplicate custom aliases
  • adding part of unique userids to prevent collision
• bad UI
  • simple clean UI that functions on all major browsers and mobile