![]() ![]() This will decide what kind of database (RDBMS or NoSQL) we need to use. We need to think about the reads and writes that will happen on our system for this amount of data. In a Year of 0.7284 TB and in 5 years 3.642 TB of data. If we calculate the total storage then for 30 M active users total size = 30000000 * 2.031 = 60780000 KB = 60.78 GB per month. The above calculation will give a total of 2.031KB per shortened URL entry in the database. Short URL size: 17 Bytes for 17 character.Consider the average long URL size of 2KB ie for 2048 characters.Let’s make the assumption given below for different attributes… Think about the different columns or attributes that will be stored in our database and calculate the storage of data for five years. We need to understand how much data we might have to insert into our system. ĭiscuss the data capacity model to estimate the storage of the system. These characters are a combination of 62 characters something like. Let’s consider we are using 7 characters to generate a short URL. For this period the service will generate about 1.8 B records. Let’s assume we store every URL shortening request (and associated shortened link) for 5 years. Let’s assume our service has 30M new URL shortenings per month. Let’s start by making some assumptions about the traffic (for scalability) and the length of the URL. Shortened links should not be predictable.URL redirection should happen in real-time with minimal latency.This is really important to consider because if the service goes down, all the URL redirection will start failing. The system should be highly available.Links will expire after a standard default time span.When the user hits a short link, the service should redirect to the original link.Given a long URL, the service should generate a shorter and unique alias for it. ![]() ![]() This will clear the initial doubt, and you will get to know what specific detail the interviewer wants to consider in this service. Ask questions to identify the scope of the system. Let’s start by talking about the requirement first…īefore you jump into the solution always clarify all the assumptions you’re making at the beginning of the interview. In this kind of question, the interviewer wants a high-level design idea where you can give the solution for the scalability and durability of the service. Most of the candidates make mistakes here and immediately they start listing out some bunch of tools, databases, and frameworks. When you’re asked this question in your interviews don’t jump into the technical details immediately. Is it really simple? Absolutely not if we think about the scalability of this service. When a user gives a long URL converts it into a short URL and updates the database and when the user hits the short URL then search the short URL in the database, get that long URL, and redirect the user to the original URL. For example, shortening the given URL through TinyURL:Ī lot of candidates might be thinking that designing this service is not difficult. You need to design this kind of web service where if a user gives a long URL then the service returns a short URL and if the user gives a short URL then it returns the original long URL. URL shortening services like bit.ly or TinyURL are very popular to generate shorter aliases for long URLs. How Would You Design a URL Shortener Service Like TinyURL? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |