System requirements

Functional:

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

- URL shortening: user provide long url, and received a shortened version.

- Redirection: user provide shorten url, we can redirect it to long url location.

- Custom Alias: user can choose alias to manage their short url.

- Account management: user can manage their url account and urls.

- Analytics: collect and display statistics like how many time url get accessed.

- API: provide API for user so user can programmatic access the shorten URLs.

Non-Functional:

List non-functional requirements for the system...

- Scalable

• Able to handle increasing load and also handle decreasing load (flexible)
• Able to handle large amounts of traffic (~1M DAU)

- Availability

• Aiming for highly available

- Consistency

• We can accept eventual consistency

- Durability

• We don't want to lose data that has been committed to the system

Capacity estimation

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

expected 1M DAU.

• each user redirect about 100 times/d
• each user create 10 new url/d

that is 100M redirect/d means ~1000TPS.

and for creating, 10M new create/d means ~ 100 TPS

assume 10kb for each new url created cost,

that is 100gb for 1 day creating.

and ~ 40tb per year.

~400tb per 10 years.

API design

Define what APIs are expected from the system...

GET: www.shorturl.com/shorten/

header: api-key, user_info, auth_token.

body:{

long_url: "www.longurl.com/params=123",

alias:"new short url 1"

}

response:{

short_url:"shorturl.com/hashcode123"

}

GET: www.shorturl.com/redirect/

header: api-key, user_info, auth_token

body:{

short_url: "shorturl.com/hashcode123"

}

response:{

long_url: "www.longurl.com/params=123"

}

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

erDiagram

    User }|..|{ UserID : has

    User }|..|{ name : has

    User }|..|{ auth_token : has

    User }|..|{ password : has

    User }|..|{ user_create_date : has

    User }|--o{ URLs : create

    URLs }|..|{ URLID : has

    URLs }|..|{ UserID : has

    URLs }|..|{ short_url : has

    URLs }|..|{ long_url : has

    URLs }|..|{ expire_date : has

    URLs }|..|{ url_create_date : has

    User }|--o{ Analysis : view

    Analysis }|..|{ URLID : has

    Analysis }|..|{ UserID : has

    Analysis }|..|{ access_count : has

    Analysis }|..|{ analysis_create_time : has

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

flowchart TD

    A[User] --input long url --> C{load balancer}

    A -- inut short url -->C

    A -- request analysis data -->C

    C --long url --> D[shorten service]

    C -- short url --> E[redirct service]

    C -- user/auth info --> F[analysis service]

    D -- store url mapping --> G[Database]

    G -- replicate --> B[Replicate Database]

    E -- request long url --> B

    F -- request analysis data --> H[analysis DB]

    G -- response long url --> E

    E -- update expire --> G

    E -- update analysis data --> H

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

sequenceDiagram

    User->>+ShortURLService: send long url

    ShortURLService->>+Shorten service: send long url

    Shorten service-->>+Database: store url mapping

    Database-->>-Shorten service: success

    Shorten service-->>-ShortURLService: short url

    ShortURLService-->>-User: response short url

    User->>+ShortURLService: send short url

    ShortURLService->>+Redirect service: send short url

    Redirect service-->>+Database: retrive long url and update expire

    Redirect service-->>+Analysis Database: create/update analysis data

    Analysis Database-->>-Redirect service: success

    Database-->>-Redirect service: long url

    Redirect service-->>-ShortURLService: long url

    ShortURLService-->>-User: response long url

    User-->>+ShortURLService: request analysis data

    ShortURLService->>+Analysis service: user info/auth

    Analysis service-->>+Analysis Database: retrive analysis data

    Analysis Database-->>-Analysis service: user analysis data

    Analysis service-->>-ShortURLService: user analysis data

    ShortURLService-->>-User: response user analysis data

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

• Database consideration
• Rational DB to store user and url mapping
• Using non-rational DB like Redis as analysis DB
• Load balance

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

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

Future improvements

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