System requirements

Functional:

- users can make acct

- user can delete account

- user can create,

update, delete maps

- want to save mappings

to a user. one to many

relationship

- reliable hash function

that generates random

hashes for URLs

- URL validation

- add URL expiration?

Non-Functional:

Performance: C or A?

Care more about

consistency

Choose SQL DB

Availability:

DB setup:

master-slave replication

Scalability:

1 LB

Cache

Security: ensure user

data is secured.

OAuth for user login

session cookies last 10 min,

otherwise user logged out

add password recovery/

forgot password

add password salt to protect

passwords in DB

Estimations:

Capacity estimation

How many users daily?

5-10K users

API design

API design

/createUser

(takes name, email, pass)

check if email

already in DB

return error if yes

else, create new user

salt password before

saving into DB

/loginUser

(takes email, pass)

decrypt pass

find if email and pass

match entry in DB

return session cookie if yes

/deleteUser

session id extracted from

session cookie

find user that corresponds

to session ID

delete row with user

user is logged out

/validateSessionId

(takes session ID)

ensures session ID

is valid

/newLongToShort

(takes session ID, longUrl)

call /validateSessionId

to ensure valid user and not

bad actor

return error and logout

user if not valid session

id

email user recommending

changing password

call /validateLongUrl to

ensure long URL is a valid url

return error if not valid URL

call /checkLongInDb

to check if already in DB

return error if yes

call /createUrlHash to

create new hash

call /mapLongToShort

to create a mapping

of long to short. add

to longToShortUrl table

if save to DB not

successful, return error

call /mapUserToMap

to map user UUID to

longToShortUrl UUID

if save to DB not

successful, return error

else, return 200

/validateLongUrl

(takes long url)

validates long

url

/checkLongInDb

(takes long url)

queries all long urls

for given user

checks if long url

matches any in the query

/createUrlHash

(takes long url) hashes it,

returns the hash

/mapLongToShort

(takes longUrl, shortUrl)

creates new entry in DB

returns 200

/mapUserToMap

(user UUID, map UUID)

creates new entry in

userToMap table

/deleteLongUrl

(user, longUrl):

check mappings

with user

check for long url

if DNE, return error

else, delete mapping

/getAllUrls

(takes sessionID)

retrieves userID from

sessionID

does query on userToMap

for every userID that matches

retrieves all longToShortId

returns an array of objects

of longToShort mappings

Database design

users table:

userID UUI

name string

email string

sessions table:

sessionID string

userID UUID

ipAddress string

createdAt DATETIME

expiresAt DATETIME

isActive boolean

longToShort table:

longToShortId UUID

longUrl string

shortUrl string

created DATETIME

expiry DATETIME

userToMap table:

id UUID

userID UUID

longToShortId UUID

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

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

Using round robin algorithm for load balancer. We won't really have heavy traffic. Not like this is a social media platform or real time platform, so RR works fine.

For DB, using master-slave replication.

Trade offs/Tech choices

I chose SQL DB over NoSQL because we are prioritizing consistency over availability. We want strong consistency. SQL databases are ACID compliant.

Failure scenarios/bottlenecks

- synchronously copying data from master to slave DB

Future improvements

• could use a batch worker to replicate master to slave DB