System requirements

Functional:

• Generate alias for a URL
• Update the original URL without changing the alias
• Get original URL given the alias
• Delete an alias
• Alias can be activated or deactivated
• on demand
• at scheduled time
• indefinitely
• Get original URL can be performed by
• Any user
• Authorised user(s) or user group(s)
• Update or delete alias can be performed by
• Creator of alias
• Authorised user(s) or user group(s)
• Insights
• Order aliases by traffic
• User should be able to customise the alias based on availability (in a premium plan)

Non-Functional:

• URL cannot be longer than 1000 characters
• One alias can refer to one URL but one URL can have multiple aliases
• Generating alias for the same URL multiple times should return different aliases
• It should not be possible to reverse engineer the original URL from the alias
• Service should be highly available because downtime would make URLs unaccessible
• Consistency can be compromised in the event of network partition
• A certain URL can be very popular and become hot

Capacity estimation

• Assume that 50 million users generate one alias/day.
• 10% of aliases take 90% of the traffic i.e. 5M URLs take 90% traffic.
• Each URL is hit 1000 times/day i.e. 5 billion requests/day i.e. 50 thousand/sec.
• On an average, an alias is active for 1 year. Hence, at any time, 365 * 50M aliases are required = 20 billion aliases. If an alias consists of a-z and 0-9 characters, we need 8 characters. For future scalability, let us take 8 characters.
• Write traffic = 500 TPS
• Read traffic = 50,000 TPS

Space requirements:

Average Orignal URL length = 100 bytes i.e. 1 kb

Average alias length = 8 bytes

20 billion aliases require = 0.1 kb * 20B = 2 Tb

API design

### Generate alias for a URL

POST /alias

Request:

• URL
• status (active/inactive) (optional)
• schedule
• activateAt
• deactiveteAt

Response:

• Alias

### Access control for an alias

POST /alias/permissions

Request:

• alias
• permissions
• operation
• actor(s)

DELETE /alias

POST /alias/activate or /deactivate

GET /alias

Database design

ALIASES table:

• id (primary key)
• alias (secondary index)
• URL (secondary index)
• createdBy
• createdAt

PERMISSIONS table:

• resourceId (primary key)
• actorId
• operation

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?