Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
List non-functional requirements for the system...
Estimate the scale of the system you are going to design...
100,000 users
10,000 daily active user
Each user generates around 5 shortened URLs per day on average
Default link expiry is 30 days but can be set to as much as 2 years.
A tiny link can be 256 bytes so worst case 36.5 MBs is needed for two years. Can fit in a single database along with user and link metadata.
Redirect Rate:
There are 5 redirects per shortened URLs so 10,000 Daily User * 5 Generated links per day * 5 redirects = 250,000 redirect traffic per day
Define what APIs are expected from the system...
GET
/short-link
redirectShortLink(String link)
returns stored link
POST
/short-link
generateShortLink(String link, String? alias, Datetime? expiration)
returns payload with tiny link
DELETE
/short-link
deleteShortLink(String link)
deletes existing short link. can be used for batch processing for expired link
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
Will go with a SQL database such as Postgres since it'll allow modeling relationships between users and links easier. Since the data can fit in a single database node, we will not need the horizontal scaling that a NoSQL database can provide.
User schema
userId - varchar(30)
password - varchar(255)
emailAddress - varchar(255)
User-Link Relationship Schema
userId - varchar(30)
shortLink - varchar(255)
ShortLink Schema
shortLinkId - varchar(30)
expirationTime - datetime DEFAULT 30 days
shortLinkAlias - varchar(255)
actualLink - varchar(255)
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
There is a client reaching out to a load balancer that directs traffic to a link-shortening service that reaches out to an SQL database. Also, there is a batch processing service that periodically evicts the database for expired links
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
For the link shortening service, it is behind a load balancer so that it will be able to respond to the 250,000 redirects that occurs per day.
The link and user data is stored in an SQL database since the data can fit in a single database and it will be easier to model the relationships between the user and the links. However, if we needed to scale the system even further, we could use consistent hashing to accomplish that.
Explain any trade offs you have made and why you made certain tech choices...
I chose to keep it simple as a monolith with a single database since it is able to handle the load needed for our requirements.
Try to discuss as many failure scenarios/bottlenecks as possible.
The biggest bottleneck would be a hot link. Some links would be more popular than others and would take a substantial hit to our service.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
A good improvement to tackle a hot link is to implement some sort of LRU cache layer so that the hottest link is served quickly to the user and does not overload the service by having to repeat the same database reads.