Loading...
Create a shortened IRL
Redirect to a Long URL from a short url
Low latency response
High uptime (24hrs)
Must be scalable
urls must not conflict with each other
how long should the short url be?
will use (a-z)(A-Z)(0-9) characters = 62 chars
62^ 6 = 56^9
62^7 = 3.5^12
seven characters needed to store all data for 10 years.
each key can be stored in a database and assigned to when needed
200 WPS
short url = 7 bytes
long url = ~ 100 bytes
user metadata = ~500 bytes
assume around 1kb per write
hold for 10 years
= 200 * 60 * 60 * 24 * 365 * 10 * 1000 = 6.3 * 10^12
= ~6.3 TB of data for writes
Estimate 10x read/write ratio
= 2000 RPS
High RPS = NoSQL database
PUT /data/url:
users provide a long url and possibly an expiration time and it is stored as:
GET /data/url/{shortUrlId}
Returns a http code 301
redirects user to the longUrl
We will be using 2 databases.
A nosql database for its high read throughput
NoSQL schema:
shortUrlId hash
LongUrl string
Expiration: datetime (defaults to 10 years)
and sql database for its ACID features and wont have to worry about collisions
SQL Keys Database:
key: string
occupied: bool
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. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
The client will input a short URL into the browser, this will connect to the web servers to use the 7 character url extension as an ID to retrieve the long URL, and then will redirect the browser to the long url.
To create a short URL the user supplies the long URL. The Keys database searches for an unoccupied key, and assigns this to be the shortURL. Ths approach is chosen over a hasshing algorithm to avoid colisions.
We should use the token Bucket algorithm to limit network traffic from a single source
The RLS shortening service will use the SHA hashing algorithm
Explain any trade offs you have made and why you made certain tech choices...
In the future we may want to use sharding in our NoSQL database to increase throughput. And to cache the most popular 20% of short urls.