![]() 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 could be 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. KGS will make sure all the keys inserted into key-DB are unique.Ĭan concurrency cause problems? As soon as a key is used, it should be marked in the database to ensure it doesn’t get reuse. ![]() Not only are we not encoding the URL, but we won’t have to worry about duplications or collisions. This approach will make things quite simple and fast. 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). This could result in key duplication, to resolve that, we can choose some other characters out of the encoding string or swap some characters. Now we only have space for 8 characters per short key, how will we choose our key then? We can take the first 6 (or 8) letters for the key. After base64 encoding, we’ll get a string having more than 21 characters (since each base64 character encodes 6 bits of the hash value). If we use the MD5 algorithm as our hash function, it’ll produce a 128-bit hash value. With 68.7B unique strings, let’s assume six letter keys would suffice for our system. Using base64 encoding, a 6 letters long key would result in 64^6 = ~68.7 billion possible strings Using base64 encoding, an 8 letters long key would result in 64^8 = ~281 trillion possible strings A reasonable question would be, what should be the length of the short key? 6, 8, or 10 characters? This encoding could be base36 () or base62 () and if we add ‘+’ and ‘/’ we can use Base64 encoding. The hash can then be encoded for displaying. ![]() We can compute a unique hash (e.g., MD5 or SHA256, etc.) of the given URL. Each api_dev_key can be limited to a certain number of URL creations and redirections per some time period (which may be set to a different duration per developer key). ![]() To prevent abuse, we can limit users via their api_dev_key. How do we detect and prevent abuse? A malicious user can put us out of business by consuming all URL keys in the current design. A successful deletion returns ‘URL Removed’. Where “url_key” is a string representing the shortened URL to be retrieved. Returns: (string) A successful insertion returns the shortened URL otherwise, it returns an error code. expire_date (string): Optional expiration date for the shortened URL. user_name (string): Optional user name to be used in the encoding. custom_alias (string): Optional custom key for the URL. original_url (string): Original URL to be shortened. This will be used to, among other things, throttle users based on their allocated quota. Parameters: api_dev_key (string): The API developer key of a registered account. Following could be the definitions of the APIs for creating and deleting URLs:ĬreateURL(api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None) We can have SOAP or REST APIs to expose the functionality of our service.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |