URL Shortener Functional Requirements

[00:00:00]
>> Jem Young: We're dropping it again, new interview, new problem, new prompts. We're designing a service that converts long URLs into shorter, more manageable links. Another exercise. Let's go ahead and do this one. URL shortening. Different domain entirely. Was this one more challenging, easier? I think MVP could have way fewer variables, way fewer product features in it.

[00:00:38]
Yeah, there's just less to do. URL shortening's already a pretty scoped problem. So the problem you're going to be solving is probably not on the UI side or the feature side, probably more on the functional requirements or nonfunctional requirements. So hopefully that's something you think about when you're going into a problem they give you.

[00:00:58]
A prompt is like, where do I need to spend my energy? A banking app or designing Instagram or something like that, that's user feature heavy. Something like this is more of a service, less than an app, so it makes it a little bit easier to reason about the UI and the UX. So what are questions you all would ask to scope this down? Do we want to put any guardrails in place so that users don't get redirected somewhere they don't want to go?

[00:01:28]
Such as like a preview or allowing them to confirm they actually want to navigate and showing them the full URL. I'm going to phrase that as a: How do we protect users from, say, malicious? I can spell. Thanks. Also, how many URLs do we want to support total? What scale? Like, yeah, 100,000 URLs. My thinking is that might determine what we can do with the short codes.

[00:02:14]
I like your thinking. Put a pin in that one for the nonfunctional requirements. You know, the reason why is: Does it matter to the user how many URLs we support? Maybe if we're saying. The question there would be, do we limit the number of URLs one user can create? Would be a functional requirement. The nonfunctional would be how many URLs do we anticipate in total, in general, per month, per year, per day.

[00:02:50]
So I'll put that one down. How many URLs are—is there a limit on URLs created per user, something like that. Can URLs expire? That would matter to the user. Yeah, my Bitly link isn't working anymore because it stops working after 30 days unless I pay. Maybe they have paid tiers for how many URLs you can use or how long they expire, like, versus a free account.

[00:03:38]
Pay tiers. I like that. Let's frame that into: Are there different levels of users? Also, is it limited to websites only, or can you do like email addresses or other protocols other than HTTP? It was a question I had which is like what constitutes a URL. I was thinking more along the lines of like, is it the origin in the base path, do we care about parameters, query params, trailing slashes, like there's something.

[00:04:21]
So what—yeah, I was going to say unrelated note. I did put down input validation or not input validation but input normalization. So like if you have two URLs with the exact same query parameters but they're in a different order, we probably should treat them as equivalent. If you care. Let's start with the first one, which is you asked about email, email address.

[00:04:49]
Does that count? Can we short link those? I'm debating if that's because it's kind of in the link URL shortener, but again, what I said earlier, I'm catching myself: don't assume anything. I was wondering, how long is too long to be considered short? Like what is a short URL? Is there a maximum limit? Maximum length. At what point is it not helpful?

[00:05:21]
Like, I'm still thinking on your question. How to phrase that? You could tie it in with, like, are URLs restricted to HTTPS or some sort of TLS encryption that requires them to be secure, so you could scope it down from excluding any other protocols besides HTTPS. That's a good way of putting it. Yeah, because what is a uniform resource locator?

[00:05:52]
Could be anything, could be a file, it could be a base64 encoded image. It's a good question to ask, yeah. Does this generate a QR code as well? Oh, what's a broader way of putting that? Is this limited to generating only a link? Yeah. I'm trying to think of how to phrase this. See, I'm not good at phrasing things simply. Limited to a link.

[00:06:39]
What's the expected output? That's a good way of putting it. What is the—back to output for a short link? Probably a better way to phrase that because I like the QR example because we're already thinking like, oh, it's just a short link, but how do you access that short link? Maybe a different way. How do we—how can the short link be represented or what's the representation of it?

[00:07:21]
Yeah. Kind of related to expiring. I was wondering if they could be edited or deleted if the user was attached to that link in some way. It's a great one. I thought of one, do we need analytics on the links? Is that an important feature? Maybe if you want to clean up them. Will this be a broader question about is there an admin panel to manage the links, yeah.

[00:08:12]
Put that up here. The different levels of users. Is there—I'll make it, we'll ask an easier question, which will be how are links managed. So I like the admin panel, but if we expand it out, we're kind of covering more bases there. I was kind of wondering if they were attached to a user or just more generic, and you could handle duplicates by giving them the same short URL.

[00:08:39]
Is it even associated with the user or is it just you go to the website or you just, yeah, that's a great question because then you could be aggressive on pruning, say. Do users need to create an account to make short links? That's a great one, so we ask that, that scopes it down substantially versus strangers doing it. Different scale of problem.

[00:09:18]
I think the answer to this is obvious, but maybe it isn't: like do links need to be unique? I think they do by the nature of the service, but it might depend on your hash. Maybe we can say, would it be fair to say this can—multiple short links link to the same long URL, is that the question you're asking? I think I was saying the, yeah, well, then the inverse is like could one short link go to multiple long URLs.

[00:10:10]
I can't, I don't think you can as the nature of the service, but I'm—it doesn't hurt to ask, but I'm, part of me is like that's a fundamental, I don't know how you would do it. Like it wouldn't be impossible. But I did say don't assume anything, so I mean I'm just catching myself here. You could extend your short link to include like a query parameter or something, but I don't think that that might be counterproductive to the whole point.

[00:10:44]
It's a good link to random websites, yeah, rushing whatever one you get you get. It's more of a game then. Pretty good. We were just saying, oh, this is such an easy problem. This is so much smaller. How hard can it be? And then I think, look at all these questions we have to ask. I think if we run through these, we could probably shorten them down a little bit, but yeah, different problems, different problems faced entirely.

[00:11:20]
So we asked the questions. What are the examples of functions? The shortening process should be deterministic. Tell me more. Like, in the sense that like, basically I'm just thinking, okay, well, you can set it up that way like you put in a link, you get a random generated URL in response, but if you've already generated that input already, you should ideally be able to reuse it and like you can sort of just like minimize the URLs that you're sort of like taking up in the database.

[00:11:52]
That's how I was thinking about it if it wasn't attached to the user, but as soon as you attach it to a user, then maybe you actually want some different URL for that if they can edit it and they can change it and do things. I like that approach better because it's easier to maintain. Let's, let me see if we can shorten this down and say users need accounts to edit the URLs.

[00:12:26]
I guess they're not even mutually exclusive. You could have a different link if it is detached to the user and then if it's just you didn't sign up, it's a random one, you could reuse it. You can have a different hashing or whatever your seed is different or like protocol for users that are registered, so they get unique links versus just deterministic hashing that has the same link given back for users that are registered and supply the same link.

[00:13:01]
Are we assuming here the users can't customize their short link? I mean, we could put it yes or no as the first question. I think if you take users out, it gets a lot simpler. Deal. I'll go with that. Yeah, it doesn't hurt. I think the worst thing to say is like, no, you have to account for this. So yeah, scope it down, make it easy on ourselves.

[00:13:46]
We could say users are limited to 50 free short links and then put up a paywall for anything more than that. Say there are free users and paid users, something like that. And we could say paid users require accounts with email and password. Something like that. Paid users have no expiration of their generated links, but free users are limited to 6 months.

[00:14:11]
Oh, you did say users can customize links. I would say if you're a paid user, you probably could edit or delete your links as well. Okay, I think it's pretty good. It's a different problem entirely. Again, I want you all to learn from my mistakes, which is, oh, I've done one system design, I can do another, but the reality is you can't, these are different problem spaces entirely, but at the end, we're still drawing, you know, boxes and arrows.

[00:14:38]
So it's about immersing yourself in that domain, thinking about it critically from multiple perspectives, what do we need to do? What's the MVP? Who are the users? What are they trying to do? What's the most important feature here and kind of honing in and narrowing down on that. All right. Nice work, everyone. This is hard. It's hard, especially when you're tired, you've been doing multiple rounds of interviews, and maybe you have two system design interviews back to back.

[00:15:08]
That's why we have the strategy, which is, let's ask questions first, let's write those down and then let's validate that. Well, I said surefire, nothing surefire, but it's a better strategy than, oh, wait, I've seen this, I've seen this one before. This is a real-time game. Yeah, I've seen this pattern before. Maybe you'll get to that level, but it's much better to have a general approach where you're not assuming anything going in because again, you don't know your mental state, you don't know what you'll be thinking about, but if you follow the same patterns, it'll lead you to a better outcome in the long run.