Loading...
If this service was well known then the daily active users could ramp up quickly through social media in particular. Expect a period of the site being niche with ~50 users and no more than a link generated a day but then it could ramp up if short urls are shared around a bunch across social media (even more if the links have the website name in them). After a month this could turn into 500 total users generating 10 links daily by the second month. After a year this could be 5000 users and 100 links generated a day if marketing efforts increase.
The read/write ratio I imagine would be more reads from tons of people using the short url to redirect to the source url. Something like 50:1.
Storage requirements would boil down to a database containing the entries / rows of source url (of potentially long string lengths) and the generated short url, with a user id associated with it. A long url could be 100 characters on average, the shorted one 10 characters. 20 bytes for meta data like the user that created it or creation date. So 130 bytes total. With the previous assumption of how the site could grow, this could mean like 100 daily entries x 365 days could amount to 36,500 database entries in a year. 36,500 x 130 bytes = 4,745,000 or 4 MB.
Bandwidth could get larger and complicated if long urls are allowed. QPS would need to be high like 100 QPS.
A POST route for submitting a url. This would check if the url is valid and if not it would return a response. Otherwise it would generate a link. That link would lead to a get request that redirects you to the actual link.
These APIs would need to have some way of limiting the number of requests a user can make to not overload this system if they spam url generating every few seconds. I.e. only 2 requests every 30 seconds. Load balancing between multiple services scaled horizontally would also work well the more and more traffic shows up. Caching would be good for any frequently accessed short urls pointing to popular websites.
Overall a system for a short url generator needs to be scaled horizontally. You want people to access and generate links quickly as this scales. Load balancers to make sure the server doesnt take forever to respond and caching for frequently accessed links is key.
An api gateway layer could be used to direct requests to two services, the link read service and link generating service.
When user reads a link we should have a link read and redirect service. A get request handles the link, connects to the database to see what link it goes to, then redirect the user to the long link. Caching is possible to use if its a frequently clicked link.
The link generator needs a post endpoint. Every link generated needs a random id string to be generated, with collision checking. The short url also can use random short strings in the same way if no custom string is specified.
This would be stored on an psql database with tables for users and links. Users can have many links. A row on a link table will have the short generated link and long links.
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
Needs at least two tables
-Users
-Links
-Links table has a short_link and long link column
-Users have ids for each link they create
-Some sort of links used column to use for caching frequently used links later
-No SQL for better horizontal scaling as the two tables are simple
-Use MongoDB for flexibility in adding indexes whenever, in case something is missed or new link features are added and the database is expanded
-Indexes on short_link for quick full link getting for redirects
-Index on user id for fast lookups of the user's generated links
Partition key: Hash of short_code for even distribution and single-node redirect lookups.Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
ID Generator service: A random string is used
-Generate a random 7-char base-62 string
-INSERT INTO links (short_code, long_url)
-If DB has a unique index on short code a collision triggers an error
-Catch the error, generate a new random string and retry (7 chars will make this rare)
Redirection Service: A get request is sent, a load balancer determines the server with the least load on it
-Cache is used for frequent (use Redis; if cache miss occurs then query mongoDB, store it in Redis, set TTL to 24 hours. Drops LRU links)
-When DB look up happens, using indexing for short code to make it scale well with millions of link rows
-301 redirect it to pass other links SEO ranking power