We can have SOAP or REST APIs to expose the functionality of our service. One thing to note here is that since there will be many duplicate requests (of the same URL), our actual memory usage will be less than 170GB. To cache 20% of these requests, we will need 170GB of memory: 0.2 * 1.7 billion * 500 bytes = ~170GB Since we have 20K requests per second, we will be getting 1.7 billion requests per day: 20K * 3600 seconds * 24 hours = ~1.7 billion 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 TBįor 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 ~20K URLs redirections, total outgoing data for our service would be 10MB per second: 20K * 500 bytes = ~10 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 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: 500 million / (30 days * 24 hours * 3600 seconds) = ~200 URLs/sĬonsidering 100:1 read/write ratio, URLs redirections per second will be: 100 * 200 URLs/s = 20K/s Let’s assume a 100:1 ratio between read and write.Īssuming, we will have 500M new URL shortenings per month, with 100:1 read/write ratio, we can expect 50B redirections during the same period: 100 * 500M => 50B There will be lots of redirection requests compared to new URL shortenings.
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. Given a URL, our service should generate a shorter and unique alias of it.Our URL shortening system should meet the following requirements: This will help you a lot in understanding this chapter. 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 to optimize links across devices, track individual links to analyze audience, measure ad campaigns’ performance, or hide affiliated original URLs. The shortened URL is nearly one-third the size of the actual URL.
Additionally, users are less likely to mistype shorter URLs.įor example, when we shortened this page through TinyURL: Short links save a lot of space when displayed, printed, messaged, or tweeted. Let’s 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. This service will provide short aliases redirecting to long URLs. Question Statement: Let’s design a URL shortening service like TinyURL. Let’s follow that approach to solve a classical system design question: Designing a URL shortening service like TinyURL.
To help with that, in my previous post, we discussed a step-by-step approach for solving system design interview questions. Even advanced and experienced developers find system design interviews challenging since the design questions are open-ended and have no standard answer.
#DESIGN TINYURL SOLUTION SOFTWARE#
Software engineers usually struggle with system design interviews partly due to their lack of experience developing large-scale systems and partly due to the unstructured nature of system design interviews.
#DESIGN TINYURL SOLUTION HOW TO#
How to design a URL shortening service like TinyURL?
0 kommentar(er)
