Designing A Simple Url Shortening Service A TinyURL Approach - System Design

Requirements

Functional Requirements:

Create a short URL for a given long URL.
Return the long URL associated with a given short URL.
Users can create accounts for authentication and manage URLs they have created
Users can create also custom short urls
Provide users with analytics on their shortened URLs, such as click counts and geographic data
Batch URL shortening
Expire URLs

Non-Functional Requirements:

The system should be highly available, scalable (storage) and low latency when redirecting URLs

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...

createShortURL

Input:
{
  "inputURL": inputURL, 
  "user_id": user_id (optional),
  "expiration_time": exp_time,
  "customName": customName (optional)
}
Output:
{
"shortenedURL": shortenedURL
}

redirectURL

Input:
{
"shortenedURL": shortenedURL,
}
Output:
{
"originalURL": originalURL
}

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.

shortURLsvc: service to shorten URL and store it in a database.
redirectionURLsvc: takes the shortened URL, finds it in the database or cache, returns the original url
Database: to store all URLs (created by shortURLsvc or by a backend process)
backend process: create unique keys in database to be used as short urls.
Analytics service: service to track analytics of urls (whenever people get redirected to that url)
analyticsdb: store analytics of urls.

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.

shortURLsvc: How to shorten URL? We can hash the url. Then, we can encode the hash with base 64 encoding to have better readability. We can take the first 6 characters of that base 64 encoding. Ex: user enters thisismycoolwebsiteletsgo.com. Our service would hash the url. Then encodes with base 64 and we would get a long string like abc32456..4332. We would then take the first 6 characters of that encoding. So final URL, would look like tinyurl/abc324.com. So in our database we would store abc324.com -> thisismycoolwebsiteletsgo.com.
- Con: We can get duplicate shortened url's. To fix this, we can keep a counter whenever we get a duplicate or rely on our backend process to get unique keys to shorten urls.
redirectionURLsvc: it just looks into the database to find the shortened url and get the original url as a value. If it is not in cache, we store it in the cache. In order for not having stale data, we can have a TTL on the url in the cache.
backend process: These unique keys will be stored in database and they can have a field as not used(meaning that it has not been assigned as a short url. It isn't mapping to any url). This is useful when we don't want to perform a calculation like hashing and then encoding, let's just take a unique key and use that as a shortened url.
- con: we would need to keep track of the keys not being used as urls

Another drawback of approach: is not straightforward to reuse shortened url's that have expired if a user is keeping track of url stats.