![]() ![]() The database can be in the form of a key-value store for faster lookup. The access token is only distributed to the registered users, and we can produce a user portal to generate URL.įor the redirection service, having 2000 redirect per second can possibly be handled by a large server. To accomodate this need, we can design the generation using an access token based REST api. The random string can be precomputed, and the URL generator simply gives out the next available string in the system.īased on business needs, we may want to restrict only the regsitered users to be able to generate URL but we want anyone to use the redirection service. The key part of URL generation is to produce a random string and store the association of that string with the original URL in the database. ![]() On the high level, we will divide the service into 2 functional components: URL generation and redirection. With this estimation, the computing power should not be a huge problem. With our 10:1 assumption, the number of URL redirection is: Our design should also take into the account that the lookup should be as fast as possible.Īssuming 100M active users generating 5 URL a month. The incoming URL needs to perform a lookup to find the original URL, and redirect with HTTP 302. ![]() Our design will attempt to optimize performance on URL generation. Generation of shortened URL involves produce a random 7 character string without conflict. Latency: There are 2 parts of the service: one is to generate the shortened URL, the other is to redirect from the shortened URL to the original page. Our service can produce an unique URL every time a URL is generated. Our assumption is that, on average, the read to write ratio is 10:1.Ĭleanup: Do we reuse the URLs that are no longer in use, or deleted by user? As 7 characters can host 3.5 Trillion URL entries, we do not need to reuse URL for a very long time. It is expected that a shortened URL is going to be used more than once. R/W ratio: How many requests per second for generating a shortened URL versus visiting a site using the shortened URL? Typically a user creates a shortened URL to share with other users, either on their Twitter message or Facebook page. That should be sufficiently small, and our service can grow for a very long time without fear of URL conflict. If we can choose a domain name that is short, such as “bit.ly”, the entire URL is a fixed size of 22 characters long. With 7 characters long, this amount to 62^7 = 3.5 Trillion URLs. Size of URL: How do we create a short URL from arbiturary number of URL without conflict? If we use alphanumeric characters, each character can represent 26*2+10 unique possibilities. If the obscure name is not found, the service can return a generic error page notifying the user that the page does not exist. Redirection: How does the shortened URL redirected to the original site? With HTTP 302 redirect, our service simply needs to know the mapping from the obscure name “2WObI46” to the original URL “ ". Services like TinyURL or Bitly are examples of such URL shortener service.įor example, my previous post on designing a web crawler’s URL is: One application of a URL shortener is to share a URL in a Twitter message, which is limited to 140 characters long. A URL shorten service creates a short alias from a longer URL. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |