Original_url (string): Original URL to be shortened.Ĭustom_alias (string): Optional custom key for the URL. This will be used to, among other things, throttle users based on their allocated quota. Following could be the definitions of the APIs for creating and deleting URLs: creatURL(api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)Īpi_dev_key (string): The API developer key of a registered account. We can have SOAP or REST APIs to expose the functionality of our service. This should explicitly state what is expected from the system. 💡 Once we’ve finalized the requirements, it’s always a good idea to define the system APIs.
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 To cache 20% of these requests, we will need 170GB of memory.0.2 * 1.7 billion * 500 bytes = ~170GB Since we have 19K requests per second, we will be getting 1.7 billion requests per day:19K * 3600 seconds * 24 hours = ~1.7 billion Memory estimates: If we want to cache some of the hot URLs that are frequently accessed, how much memory will we need to store them? If we follow the 80-20 rule, meaning 20% of URLs generate 80% of traffic, we would like to cache these 20% hot URLs. We will need 15TB of total storage:30 billion * 500 bytes = 15 TBSAVERESETīandwidth estimates: For write requests, since we expect 200 new URLs every second, total incoming data for our service will be 100KB per second:200 * 500 bytes = 100 KB/sįor read requests, since every second we expect ~19K URLs redirections, total outgoing data for our service would be 9MB per second.19K * 500 bytes = ~9 MB/s Let’s assume that each stored object will be approximately 500 bytes (just a ballpark estimate–we will dig into it later). Since we expect to have 500M new URLs every month, the total number of objects we expect to store will be 30 billion:500 million * 5 years * 12 months = 30 billion Storage estimates: Let’s assume we store every URL shortening request (and associated shortened link) for 5 years. URLs redirections per second, considering 100:1 read/write ratio:50 billion / (30 days * 24 hours * 3600 sec) = ~19K/s New URLs shortenings per second:500 million / (30 days * 24 hours * 3600 seconds) = ~200 URLs/s What would be Queries Per Second (QPS) for our system? Traffic estimates: If we assume we will have 500M new URL shortenings per month, we can expect (100 * 500M => 50B) redirections during that same period. Let’s assume 100:1 ratio between read and write. There will be lots of redirection requests compared to new URL shortenings. Our service should also be accessible through REST APIs by other services.Analytics e.g., how many times a redirection happened?.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.Our URL shortening system should meet the following requirements: Be sure to ask questions to find the exact scope of the system that the interviewer has in mind. 💡 You should always clarify requirements at the beginning of the interview. This will help you a lot in understanding this chapter better. If you haven’t used before, please try creating a new shortened URL and spend some time going through the various options their service offers. URL shortening is used for optimizing links across devices, tracking individual links to analyze audience and campaign performance, and hiding affiliated original URLs. The shortened URL is nearly one-third of the size of the actual URL. 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. Similar services: bit.ly, goo.gl,, etc.ĭifficulty Level: Easy 1. This service will provide short aliases redirecting to long URLs. Let’s design a URL shortening service like TinyURL.
0 kommentar(er)
