System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

• New URL is <= 11 characters long (8 chars + '.ly') this should result in roughly 2.82e12 unique combinations (36^8)
• New URL is unique and redirects to user's original URL
• Users do not need to be logged in (can be guests)

Non-Functional:

List non-functional requirements for the system...

• Service should return the shortened URL in <= 1000ms
• Service should have >= 99.9% availability
• Service should rate limit users to <= 25 POST requests per hour to prevent abuse

Capacity estimation

Estimate the scale of the system you are going to design...

• 1,000,000 daily active users (DAU)
• During peak use, 400,000 users in the same hour, potentially 25,000 concurrent users
• Each originUrl contains roughly ~14 characters --- 14 bytes * 25,000 (max concurrent users) => 350KB of data at max load

API design

Define what APIs are expected from the system...

• POST /v1/url
  • User can submit a URL to be shortened
  • POST body:
    • originUrl --- string (required)
  • This endpoint should also perform some sort of hashing to generate a unique URL
    • This will be expanded on later
  • Stores the newly created URL object into the DB
  • Returns the newUrl from the URL object
• GET /v1/url/:id
  • Server can retrieve a URL by its id (we'll be using uuid)

Database design

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...

We can just use PostgreSQL for this database as it does not need the flexibility of noSQL. Plus the ACID compliance of SQL is very useful for our data as well.

model

attributes

• id (primary key) -- string (UUID)
• createdAt -- datetime
• originalUrl -- string
• newUrl -- string

High-level design

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...

Request flows

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...

• The client makes a request via POST /v1/url on the website through a text input for the originUrl
• The server takes the originUrl and then performs hashing on it to generate a unique destinationUrl string and then stores it into the database
• The server then returns that newly created url to the client

Detailed component design

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 hashing algorithm I would potentially consider just hashing the originUrl using SHA256 or any other potential known hashing algorithms then just trim the first 8 characters.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

I think the use of PostgreSQL is valid for this case.

Pros:

• ACID compliant

Cons:

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

• None that I can think of, it seems like for the given example we would not run into conflicts e.g. if there's a race condition to create the newUrl, then it would simply fail when trying to store it into the DB and try to create a new one.
• Potentially server load can end up high if the number of DAU and peak load times continues to scale, in which case we should consider a load balancer somewhere. In that case we can distribute the load in a round robin style with a few <= 4 servers I think would suffice.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

• Not auditing for blacklisted sites
• Not checking for invalid originUrls