System requirements

Functional:

* Ability to create a new tiny URL

* Ability to convert a tiny URL to the full URL

Non-Functional:

* Availability should be 5 9s

Capacity estimation

* 100,000 a day

API design

• create(url : string) : string
• get(tinyUrl : string) : string

Database design

* A single NoSQL table where the key is the tinyURL and the value is the original URL

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

Request flows

* ON a create, the client will call the API, Load balancer will assign the request to a server who then validate it and write it to a database

* On a get, the client will call the API, load balancer will assign the request to a server who will then check the database for it

Detailed component design

* For the database, we can use a NoSQL database with persistence, e.g. Dynamo, Mongo, or Redis with snapshotting. I tend to lean towards Dynamo. It might be a tad overkill for this case but it enables us to get out of the management and scale game well. We can turn on DAX caching around Dynamo which is a write through cache. We can also add caching at the APIServer level with memcached. We could even explore getting into CDN caching.

Trade offs/Tech choices

* How many caches and where. We can start by adding them at the APIServer level, but we can get into them at the cdn level too. Maybe both. Can performance test.

* Immutability vs mutability

* Censor controls

Failure scenarios/bottlenecks

* Deleting a bad URL would not scale

Future improvements

* Implement querying tools to identify and delete bad URLS