System requirements

Functional:

The SYSTEM should return the TinyURL when a long URL is provided and mapped to a TinyURL.

The SYSTEM should create and return a TinyURL when a long URL is provided, and the long URL is not mapped to a Tiny URL

The SYSTEM should maintain the Tiny URL mapped to the long URL for 5 years.

The SYSTEM should return the long URL mapped tot he TinyURL when the TinyURL exists.

A TinyURL will be defined by 14 bytes, 1 byte of server ID, 4 bytes to represent the date, 3 bytes to represent the time and the last 6 bytes to represent the fractional seconds.

Non-Functional:

• Scalability
• Availability over consistency: We want the system to be available. The only consequence of having to URLs mapped to one Long URL is just memory space.
• Low Latency: The tinyURL should provide as minimum overhead as possible.

Capacity estimation

• Write Operation: Once a Tiny URL is mapped to a Long URL no additional write operations are required. It is assumed that 1 write operation per second.
• Read Operation: Once a tiny URL exists, it will be stored by 5 years, 100 reads per second
• Storage: Since a Columnar Database, such as Cassandra, will be used, the system will be scalable, available, and partition-tolerant.

API design

GET: Get_TinyURL

{

"TinyURL" : <Tiny URL>,

"Long URL" : <long URL>

}

DELETE: Delete_URL

{

"TinyURL" : <Tiny URL>,

"Long URL" : <long URL>

}

Database design

Columnar Database: Cassandra. Cassandra guarantees the database will be scalable, available, and partition tolerant.

TinyURL : Primary Key

LongURL : Secondary URL

High-level design

• Load Balancer: This component will balance the traffic load across all the servers in the system.
• Application Servers: This component will implement the following use cases: 1) Create the TinyURL when the long URL is not mapped to a Tiny URL on the cache or Cassandra, store it on the cache, and store it at Cassandra. 2) Return the TinyURL mapped to the longURL if the TinyURL is mapped on the cache. 3) Add the TinyURL to the cache if it exists at Cassandra but not on the cache. 4) Delete the TinyURL from the cache and Cassandra if it is 5 years old, or the user requests it.
• Reddis Cache: Will act as a low latency temporary store
• Cassandra Columnar Database will store all the mappings for 5 years.

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

Application Servers: The algorithm to generate the Tiny URL will use a timestamp adding as a prefix the id of the server generating the Tiny URL. Considering the Write Operation will be about 1 / sec, a timestamp with the server ID as a prefix will be enough to avoid collisions and generate unique URLs.

Trade offs/Tech choices

Two TinyURLs mapped to a Long URL. Cassandra prioritizes Availability and Partition Tolerance over Consistency. However, due the use case of the Tiny URL, there customer experience will not be affected if either of the two generated Tiny URLs are used.

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?