Interview Bootcamp
Vote

0% completed

​

Designing a URL Shortening service like TinyURL

Every case study in this chapter follows the same seven steps from System Design Interviews: A step by step guide, and builds its design from the components in the System Design Master Template. Keep both open beside you, and try each problem yourself before reading the solution.

.....

.....

.....

Like the course? Get enrolled and start learning!
R

Richard Yuan

· 4 years ago

For the database selection, why are we proceeding with a NoSQL database? I thought there is a relationship between the URL and User tables with the UserID field. Wouldn't that qualify as a relationship and therefore require a SQL database be used?

Show 2 replies
N

Nevil

· 4 years ago

Another question that came up in my mind:

we calculate the scale of the system in every example. What's the importance/use of it? Of course it does tell the interviewer that candidate can think in terms of scalability of individual components - like storage, cache etc. ; unless one has designed lots of systems and knows benchmarks around such numbers, this wont help much? Thoughts?

Show 1 reply
H

Haixiao Yang

· 4 years ago

What's the point of key generation service and all the complexity related to it? Just to avoid generate duplicate short url for the same long url? We can just use a encoding algorithm with salt (BASE64(SAH256(long url , salt))). The salt can just be a random generated number.

Show 2 replies
N

Nevil

· 4 years ago

Few questions:

1)When we say "We can compute a unique hash (e.g., MD5 or SHA256, etc.) of the given URL" . There still are chances that hash is not unique, i believe it would be a good call out. And this level should suffice for the technical interview at least.

2)What is the exact problem we are emphasising when we say what if parts of url are URL encoded? e.g., http://www.designgurus.org/distributed.php?id=design , and http://www.designgurus.org/distributed.php%3Fid%3Ddesign

Does this mean that if user wants to shorten both of these , we should just tell that its already shortened for this user. Also, i don't see any solution to this problem in the Workaround section.

Show 1 reply
Raunak Baliyan

Raunak Baliyan

· a year ago

Hey, i think the final diagram is missing here.

Show 1 reply
Y

Yoni

· 4 years ago

Analytics was one of the requirements, but I don't see any treatment of this in the answer. How to store it in the DB, bandwidth, async so it doesn't block redirect calls, etc.

Show 3 replies
Vibhor Kashmira

Vibhor Kashmira

· 3 years ago

Shouldn't we return 403 Forbidden instead of 401 Unauthorized if the user isn't authenticated to access the resource? This because, 401 is fixed by reauthentication, but 403 won't be fixed by that.

Show 1 reply
A

Andre Lucas Santos Silva

· 3 years ago

Hello folks. I was thinking about the KGS implementation, and after thinking about that.

Could I suggest in the system design interview generated to each URL shortened with the unique ID together?

Something like this:

var pk = ();
var shortenedUrl = pk + "-" + originalUrl
var keyShortenedUrl = ("SHA-256").digest(shortenedUrl)

repository.save(new Model(pk, originalUrl, ("%032X", new BigInteger(1, keyShortenedUrl))));

In this way, I think that we can't key duplication/collision between the keys shortened. What do you about this?

A

Alex Wells

· 4 years ago

Hi, are there any downsides to partitioning 1 keys table instead of creating 2 separate tables? I believe this helps us with database normalization

Show 1 reply
M

MH

· 5 years ago

Why should the amount of cache be estimated based on the total number of requests per 24 hours? Why not the total requests per hour, 12 hours, a year, or simply all stored URLs?

Show 1 reply