I’m reading one book right now where some URLs are spreading over multiple lines in the text and typing them by hand is a nightmare. The problem I’m encountering as both a writer and a reader is that URLs, especially technical URLs, are getting progressively longer. The article, Secure Options for URL Shortening, discusses the whole matter of URL shortening security in more detail, but at least some organizations still don’t trust the process. For example, a TinyURL URL has the host in it. Some statistics worth tracking: country of the visitor, date and time of access, web page that refers theĬlick, browser, or platform from where the page was accessed.At one point in my career I avoided the use of URL shortening sources because readers complained that they couldn’t be sure where the URL would take them. Since storage is getting cheap, we can decide to keep links forever. Should we remove links that haven’t been visited in some length of time, say six months? ThisĬould be tricky.After removing an expired link, we can put the key back in the key-DB to be reused.We can have a default expiration time for each link (e.g., two years).This service should be very lightweight and can be scheduled to run only when the user A separate Cleanup service can run periodically to remove expired links from our storage andĬache.Whenever a user tries to access an expired link, we can delete the link and return an error to the Between Application Servers and Cache servers.Between Application Servers and database servers.Between Clients and Application servers.We can add a Load balancing layer at three places in our system: The last sixĬharacters of this URL is the short key we want to generate. In the TinyURL example in Section 1, the shortened URL is “ ”.
#DESIGN TINYURL HOW TO#
The problem we are solving here is, how to generate a short and unique key for a given URL. A NoSQL choice would also be easier to scale. Need to use relationships between objects – a NoSQL key-value store like DynamoDB, Cassandra or What kind of database should we use? Since we anticipate storing billions of rows, and we don’t We would need two tables: one for storing information about the URL mappings, and one for the user’s There are no relationships between records-other than storing which user created a URL.Each object we store is small (less than 1K).Database DesignĪ few observations about the nature of the data we will store: Where “url_key” is a string representing the shortened URL to be retrieved. User_name (string): Optional user name to be used in encoding.Įxpire_date (string): Optional expiration date for the shortened URL.Ī successful insertion returns the shortened URL otherwise, it returns an error code. Original_url (string): Original URL to be shortened.Ĭustom_alias (string): Optional custom key for the URL. Things, throttle users based on their allocated quota.
System APIsĬreateURL(api_dev_key, original_url, custom_alias=None, user_name=None,Īpi_dev_key (string): The API developer key of a registered account. New URLs 200/s | URL redirections 20K/s | Incoming data 100KB/s | Outgoing data 10MB/s | Storage for 5 years 15TB | Memory for cache 170GB 4. Let’s assume 100:1 ratio between read and write.Īssuming 500 million new URLs per month and 100:1 read:write ratio,įollowing is the summary of the high level estimates for our service: There will be lots of redirection requests compared to new URL
0 kommentar(er)
