System requirements

Functional:

• User should be able to input long url and output tinyURL
• tinyurls should redirect user to longurl location
• tinyurls should be optionally expirable
• allow users to customize their tinyUrl

Non-Functional:

• Availability
• eventual consistency
• performance

Capacity estimation

• I'm assuming we could have billions of db entries overtime
• probably 10:1 ratio of reading to writing tinyurls

API design

Rest api seems good here due to rigid requirements and simple requests

POST /v1/users/:uid/tinyurl {longUrl: string, customizedUrl (optional) = nil}

GET /v1/users/:uid/tinyurls

GET /v1/users/:uid/tinyurl/:tinyID

PUT /v1/users/:uid/tinyurl/:tinyID {same as post}

Database design

Use NoSQL since we don't need strong consistency & we want to scale to huge quantities

TinyURLS

• id
• long url
• tiny url
• created_by userid
• date created

High-level design

• microservice design since read & write will have vastly different scale
• client -> apigateway
• apigateway -> read service
• apigateway -> write service
• read and write services access noSQL databases
• read service has caching

Request flows

• when you create a tinyURL, you hit the POST endpoint in the apigateway which accesses the write service, generates the tinyurl, writes it to the db and serves it back to the user
• when you click a tiny url, you access the apigateway GET endpoint which directs you to the read service, which then accesses teh db to find your tinyurl and the longform url, then redirects the user to the longform url location

Detailed component design

Trade offs/Tech choices

• nosql, which is faster and more scalable but less consistent. this is fine for us because we're worried about scale and don't mind being eventually consistent
• Same for a caching system, improves performance at the cost of consistency which we're ok with
• We could implement a load balancer as we scale horizontally to allow us to improve performance and availability again at the cost of increased complexity and a new bottleneck
• we could consider a queueing system but I don't think there's any particularly costly calculations being made, this could improe performance for writing the tinyurls but seems unnecessary
• we could shard our nosql dbs to increase reading/writing availability as needed and store replications of those shards if we're worried about losing data

Failure scenarios/bottlenecks

• the load balancer failing, the api failing are our main bottlenecks. we could improve our odds of success by reserving multiple of these services at the cost of additional complexity and expense

Future improvements

I listed these already above