System requirements

Functional:

The system allows users to shorten URLs:

• Generation of short unique URLs based on a long URLs (short URLs can be customized)
• Redirection to the original long URL
• Basic user management (account creation, login/logout, ability to view the users created short URLs)
• Analytics (amount of redirections for each short URLs) and various statistics such as geographic information
• The short URL should expire after a certain amount of time
• API integration for advanced users
• Error handling (URL that no longer exists...)

Non-Functional:

Performance requirements:

• Low latency for URL redirection should be low (less than 100ms)
• URL lookup in less than 10ms (caching will be necessary)

Availability:

• Uptime of 99.9%

Reliability:

• Strong consistency

Security:

• DoS protection
• Anti-phishing protection

Capacity estimation

Users and traffic growth:

• 1 million users in the first year
• 10% more users per month
• 10-30% are users creators (create about 4 shorts URLs daily)

Requests estimation

• 4 short URLs/day for 30% of 1M users : 300000 * 4 * 365 = 438 millions short URLs created each year

Storage requirements:

• With average of 100 chars/URL : 40GB/year

API design

string ShortenUrl(string longUrl)

string GetOriginalUrl(string shortUrl)

string DeleteUrl(string shortUrl)

string SuspendUrl(string shortUrl)

Database design

There is no very complex relationships in the data model. We can consider a NoSQL technology (key-value store for instance) in order to scale better.

The service is more read intensive than write so it can scale by adding more read replicas of the database.

The url lookup can be made faster by using a distributed cache.

Url entity

• [PK] id
• [FK] owner_id
• short
• long
• creation_date
• redirection_count
• active

User entity

• [PK] id
• email
• password
• creation_date

High-level design

The client can be an anonymous user who clicked on a short URL or a authenticated user who wants to edit urls.

A load balancer is used to distribute evenly the requests from all users among serveral application servers. It could also be used as a rate-limiter.

Reading: servers will look for the urls first in the distributed cache and then in the database if the requested url isn't cached.

Writing: requests are pushed to a distributed queue so the service can handle peaks

Request flows

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?