![]() ![]() To solve this, we can have a standby replica of KGS. Isn’t KGS the single point of failure? Yes, it is. If we need one byte to store one alpha-numeric character, we can store all these keys in:Ħ (characters per key) * 68.7B (unique keys) = 412 GB. What would be the key-DB size? With base64 encoding, we can generate 68.7B unique six letters keys. For that, it must synchronize (or get a lock to) the data structure holding the keys before removing keys from it and giving them to a server KGS also has to make sure not to give the same key to multiple servers. If KGS dies before assigning all the loaded keys to some server, we will be wasting those keys–which is acceptable, given the huge number of keys we have. This ensures each server gets unique keys. KGS can always keep some keys in memory so that it can quickly provide them whenever a server needs them.įor simplicity, as soon as KGS loads some keys in memory, it can move them to the used keys table. As soon as KGS gives keys to one of the servers, it can move them to the used keys table. KGS can use two tables to store keys: one for keys that are not used yet, and one for all the used keys. Servers can use KGS to read/mark keys in the database. How can we solve this concurrency problem? If there are multiple servers reading keys concurrently, we might get a scenario where two or more servers try to read the same key from the database. This approach will make things quite simple and fast.Ĭan concurrency cause problems? As soon as a key is used, it should be marked in the database to ensure it doesn’t get used again. Whenever we want to shorten a URL, we will just take one of the already-generated keys and use it. We can have a standalone Key Generation Service (KGS) that generates random six letter strings beforehand and stores them in a database (let’s call it key-DB). High level estimates: Assuming 500 million new URLs per month and 100:1 read:write ratio, following is the summary of the high level estimates for our service: New URLsĬreatURL(api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)Įncoding actual URL : Base64 (a-z, A-Z, 0-9, “-“, “.”Īppend an increasing sequence number to each input URL to make it unique, Generating keys offline Let’s assume 100:1 ratio between read and write. Shortened links should not be guessable (not predictable).URL redirection should happen in real-time with minimal latency.This is required because, if our service is down, all the URL redirections will start failing. The system should be highly available.Users should also be able to specify the expiration time. Links will expire after a standard default timespan.Users should optionally be able to pick a custom short link for their URL.When users access a short link, our service should redirect them to the original link.Given a URL, our service should generate a shorter and unique alias of it.Additionally, users are less likely to mistype shorter URLs.įor example, if we shorten this page through TinyURL: Short links save a lot of space when displayed, printed, messaged or tweeted. We call these shortened aliases “short links.” Users are redirected to the original URL when they hit these short links. URL shortening is used to create shorter aliases for long URLs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |