System requirements

Functional:

The User should be able to get a short format of the URL he provides

The short URL should direct the user to the original URL

the user can retrieve and update his profile

Non-Functional:

the system must be reliable and available and scalable so as to store massive amount of data

less than 100ms of downtime per week and a total availability of 99.99% to ensure URLs always 're directing to original URLs that's critical because entire systems may rely on this service on their internal logic system

Capacity estimation

let's say we have an estimated rate for 1:100 for write/read rate so our system is read-heavy

let's say we have around 200 requests/s to create URLs so 20000 read requests/s

let's say every second we create around 200 URLs and every URL has around 20 bytes and the metadata (like creationDate and lifespan time) so it's around 100 bytes so the bandwitch for writing is 20Kbyte/s and then we need around 3600 * 20Kb/s =72Mb/hour and 1.5Gb/day so the fast growth must be well handled (Cassandra) with scaling

API design

POST /shorten transform URL

GET /{url}

GET/Profile/{userId} fetch profile

Update /Profile/{UserId} update something in profile

Database design

for URLs database we use cassandra and the columns may be (id , newURL,OriginalURL,Lifespan,CreatedAt) and UserDb we need a relation database for ACID and reliability (avoiding data loss) so the schema is (UserID,name,Email,Age..)

High-level design

we need a webserver to render our static website (HTML CSS Js).this webserver must handle efficiienlty concurrency so we prefer Nginx then for dynamic requests that need database fetching we have a user server that stores users profiles and Encoding server that transforms the URL to a shorter one using hash and then store the original url and the new one in a database that supports scaling to handle massive growing data and availability of the system so we prefer Cassandra or DynamoDB for UserDB we prefer a relational database like Postgresql

Request flows

the request for user profile will be handled by Nginx(webserver and API gateway) and forwarded to UserServer for fetching

the request for adding a url will be forwarded to Encoding server for hashage and stored in URLs database

the request of the URL will be forwarded to the webserver tha will retrieve the original URL from the Encodage server and then render the original website (redirecting)

Detailed component design

Encoding server will use a hash function to hash the original URL and User server is just a normal app server

Trade offs/Tech choices

choosing availability and partition tolence over consistency we must expect a data loss or latency in synchronization of Data but for our case that's not important that much as it can be estimated by just some milliseconds

Failure scenarios/bottlenecks

we must duplicate servers to avoid single point of failure (if we use Cassandra for DB availability's gonna be fine as Cassandra is perfect for scaling) and if we use Nginx as a webserver it's gonna improve performance of the system because Nginx supports concurrency.We must use Master/slave for userDB and synchrounous synchronization between them to ensure consistency and read/write traffic segregation

Future improvements

maybe add a load balancer and message brokers for storing urls transformation events to ensure high throuput and using like a cache for recent and frequent visited urls metadata