Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.
• Each tinyurl should be unique, can do hashing or allow users to customize

Non-Functional Requirements:

• You want this to be quick, latency should be low. Probably with horizontal scaling
• You want read (aka api get requests) to be fast
• Write should be quick too but not as critical as making read as fast as possible
• This thing should always be available, we want high uptime

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

• GET: should have a get request that accepts a short url and returns a long url
• POST: should have a post request that takes a long url and returns a short url
• Before the POST, there should be a validation GET request that confirms that the tinyurl being requested is valid and doesn't already exist

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

• Obviously have the user client
• The server should be used to handle the api requests
• Then we want a database to store url mappings.
• There should be 3 main services: an id creation service, a shortening service, and a retrieval service
• The storage layer should save the long url, short url, and an ID for quick retrieval

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

• If we want to scale this, we could add a load balancer and that maps requests for servers. Maybe assign to server based on shortest queue
• For the database, if this is getting sufficiently large, we could use sharding to make it easier to retrieve data. We would probably want to shard by tinyurl so the system can route directly based on a GET request since that's what we're optimizing for
• We want to cache the most frequently requested urls across the whole system, not just the user level. You could even cache geographically, since we're using a CDN you can cache the most relevant URLs in say the EU on a CDN in the EU
• Given that we want high availability, we will also want redundancy. I'm assuming that the CDN and server is where we want the most redundancy. We can also add some redundancy on the databases