It is a read heavy distributed system and I understand that we can add cache (hash of the short url: long URL) to speed up redirection upon the click of short URL.We can have SOAP or REST APIs to expose the functionality of our service.I have been going through system design discussions for TinyURL problem and have a couple of questions on the same. 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: One thing to note here is that since there will be a lot of duplicate requests (of the same URL), therefore, our actual memory usage will be less than 170GB. To cache 20% of these requests, we will need 170GB of memory: Since we have 20K requests per second, we will be getting 1.7 billion request per day:Ģ0K * 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:īandwidth estimates: For write requests, since we expect 200 new URLs every second, total incoming data for our service will be 100KB per second:įor read requests, since every second we expect ~20K URLs redirection, total outgoing data for our service would be 10MB per second: Let's assume that each stored object will approximately 500 bytes. Since we expect to have 500M new URLs every month, the total number of objects we expect to store will be 30 billion:ĥ00 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. What would be Queries Per Second (QPS) for our system? New URLs shortenings per second:ĥ00 million / (30 days * 24 hours * 3600 seconds) =~ 200 URLs / secĬonsidering 100:1 read/write ratio, URLs redirections per second will be:

Traffic estimates: Assuming, we will have 500M new URL shortenings per month, with 100:1 read/write ratio, we can expect 50B redirections during the same period: Let's assume a 100:1 ratio between read and write. There will be lots of redirection requests compared to new URL shortenings. 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. Non-Functional Requirements: The system should be highly available. Users should 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. This link should be short enough to be easily copied and pasted into applications. The URL shortening system should meet the following requirements:įunctional Requirements: Given a URL, our service should generate a shorter and unique alias of it. Short links save a lot of space when displayed, printed, messaged, or tweeted. Users are redirected to the original URL when they hit these short links.

URL shortening is used to create shorter aliases for long URLs.

System design tinyurl