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
• You probably also will want to scale this horizontally rather than vertically
• You also want low redirect latency

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
  • We can update the cache whenever a shortening service is used to update an existing URL by storing the IDs of cached objects and then quickly reading if the ID of the updated URL is contained in the cache, if so update the alias URL in the cache
  • We can refresh the cache every 4-6 hours in case a specific website is starting to go viral. In times of mega virality, we can also create a workflow that automatically adds to cache if get requests go above X in a given hour (after accounting for rate limiters and bad actors)
• 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
• ID generation and shortening service
  • Quickly check for duplicates and use a hashing function to make sure default urls are not predictable
  • We can use different random seeds to limit the odds that a duplicate shortened url is generated in times of high demand