designing a url shortening service like tinyurl

Everything should be infinitely extendable. They say, programmers accept only three kinds of numbers: 0, 1, ∞. That said, the short link abcdefg should always go to the same shard, no matter what, and the number of shards is surely to be increasing. The best approach to shuffle the requests between different “shards” (whatever it means in this context) would be Hashring, but there is an issue: changing the size of the hashring (scalability!) on the fly would result in rehashing, and this is not something we can afford. The cool story about the task is we don’t need the highly coupled storage, even more: we don’t need it to be coupled at all. we start with an approach to handle some traffic, keeping in mind the scalability.we don’t choose the backend to store the links right away.the service must be optimized for reads over writes.My approach would be slightly less biased from scratch. Wait, what? Who said we ever need a database? Then the author compares RDBMS against NoSQL, and comes to the controversial conclusion “handle this amount of huge traffic on our system relational databases are not fit and also it won’t be a good decision to scale the RDBMS.” That was the exact place in the original post where I decided, OK, I’ll write down how would I handle it. The ability to not keep track of backward references ( Long → Short) makes it easy to forget about hashing at all and just use random sequences as ID, btw. Here I went to BitLy and made sure they don’t. The latter approach is way harder to implement, but usually we don’t care about that. Before discussing what hashing technique to use, we should clarify the most important requirement: should we generate the new short URLs for the same long URL upon subsequent requests, or shall we return the already generated one. To convert a long URL into a unique short URL we can use some hashing techniques like Base62 or MD5.Įh. If you are hired to handle the existing traffic of 30M/m, you’ll be asked very different questions during the interview, like “what the existing service are we to buy,” trust me.

Do assume the service might grow to handle millions new shortenings per month and be ready to scale. Let’s assume our service has 30M new URL shortenings per month. Thinking in advance pays back better than fixing issues afterward.īut then the author rushes into the abyss of unjustified assumptions, framing themselves in the illusion of a lovingly constructed ivory tower. This is a great statement, I would even broaden it to “When you have a task to solve, don’t jump into the technical details immediately.” The time you actually type a solution using your keyboard should not increase 10–20% of the whole time spent on the task. When you’re asked this question in your interviews don’t jump into the technical details immediately. The aforementioned post starts with the wise bit of advice What I read made me promise to propose my own solution, because accepting what is suggested there was hard if not impossible. To my pity, I am an inquisitive person, that’s why I immediately jumped into reading it. It is “How would you design an URL shortener service like TinyURL?” One of my friends pointed me to the solution of kinda popular nowadays interview task.

Designing a url shortening service like tinyurl