System requirements

Functional:

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

1. Company client should send a long url and the server could returns a short url
2. User client should send a short url and server returns the long url for redirection
3. short url should be within 10 letters following domain

Non-Functional:

List non-functional requirements for the system...

1. latency should be around 200ms
2. user should have the option to create a custom domain url
3. company user should be able to add an expiration time
4. server should records the # clients hit the short url
5. if the url expires, or hasnt been added to the db, server should returns

Capacity estimation

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

long: 100 character = 100 byte

short:short domain + 10 characters -- 20 characters 20 byte

createAt: 10 bytes

updatedAt: 10 bytes

1 million url, 0.14GB

(1000 new url per day * 30 *12 * 3years= 1 million url in db)

shortUrl: 20 byte

count: each url is touched 1000 times -- 4 bytes

1 million url, 10E6 * 25 = 25 MB

target market small business, peek estimation:

• 1000 new url perday, urls created last week are more likely to be clicked
• each url has 1000 clicks per day
• E7 total clicks, peek is at off time 7pm to 11 pm
• 600 per second

load balancing, redis, cdn?

API design

Define what APIs are expected from the system...

• POST/shorten

request body: {"url": "https://...", "expiration?: "}

response: {"shorturl": "https://short.url"}

• GET/{shortUrlPath}

response: 302/301 redirect, 302 is more suitable since its temporary redirect so the site doesnt cache the redirect

error response:

503 service unaviable, short url hasnt been updated to the db yet, ask client to retry in 1 min

410 gone, short url has expired

• Get/shorten/stats/{shortUrl}

Response:

{"shortUrl": "https://shorturl/...",

"longUrl": "https://...",

"cliclCount": 100,

"createdAt": "*******"

"expiredAt": "*******"

}

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

a sql db:

INDEX on shortUrl

url: [shortUrl, longUrl, expiratedAt, createdAt]

stat: [shortUrl, count]

the url is high read low write, stat is high write low read

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

User Interface: web front end

URL shortening service:

1. url + timestamp -> hash -> base 62; then check for conflict. if conflict, hash again
2. INCR the count -> hash -> base 62 -> check for conflict. if conflict regenerate hash

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

check my sequence diagram

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

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?