System requirements

Functional:

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

receive url + return shortened url

receive traffic to shortened url + redirect to real url

[stretch] allow links to expire for security

Non-Functional:

List non-functional requirements for the system...

reliability (should not lose links)

availability (accessing short link should feel like accessing real links) -- 99.99% uptime

scalability (these things should continue to be true as traffic increases)

[stretch] security

Capacity estimation

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

this design will be read-heavy -- far more users accessing links than saving them

20,000 req/s for redirects

200 req/s for creates

we will only have a small amount of metadata to store, ~500 bytes/link?

API design

Define what APIs are expected from the system...

create short url:

POST /api//url/

-d {

"fullUrl": ,

"expireOn":

}

returns: short-url or 4xx

redirect short url:

GET

performs redirect with 301 status

[stretch] delete / expire short url

• if we did this, we may need auth

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

this should be a relationship db (postgres, cockroachdb, etc)

short url table:

• full_url: varchar
• short_url: varchar
• created_on: datetime
• [stretch] expire_on: datetime
• [stretch] user_id: varchar

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

see diagram

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

create short url:

• user will call the "create short url" endpoint with full url
• request will be routed to a distributed node for synchronous handling
• node will generate a short url depending on desired short url design: e.g. hashing the full url, generating a UUID, etc.
• short url will be stored along with full url and other metadata in db
• short url will be returned to user along with other metadata

use short url:

• user will attempt to access short url
• short url will be received by redirect endpoint on one of distributed nodes
• node will need to retrieve full url -- check cache and retrieve from db if not present
• redirect user to full url

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

• requirement is read-heavy, so supporting reads > writes with db read replicas
• supporting high availability with distributed servers
• supporting data reliability by using single-leader replication

Trade offs/Tech choices

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

• chose to have all url logic within a single service (deployed on multiple nodes) -- this keeps domain-specific logic colocated and does not overly complicate the system
• to support a more write-heavy system, we could partition dbs or use a different replication approach. this is not needed for the access patterns of this system

Failure scenarios/bottlenecks

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

• high traffic can overwhelm any system. this design is horizontally scalable
• if there is a need for security or link updates, this system is vulnerable due to lack of authn/authz

Future improvements

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

• add auth
• add link expiration
• add link updates