System requirements

Functional:

should handle lots of data

Non-Functional:

List non-functional requirements for the system...

Capacity estimation

1 trillion shortened urls

API design

create alias

look up alias

Database design

Add a tablel

short_to_full

shortended url -> full length url

full_to_short

full url-> short url

High-level design

create requests will flow into and be written to the casanada db. We'll use Casandra's db trasnaction feature to write to both the full to short table and the inverse. If a tiny url alreayd exists for the url in question, we'll jus treturn that to avoid duplicates

Request flows

On read requests, we'll look up the short url in the short url to full table and then issue a redirect to the full url.

Detailed component design

The Casandara trasaction will ensure that teh 2 tables are eventualy consistent. Using casandra will allow the system to scale horizonally.

Trade offs/Tech choices

A no sql db is harder to work with than using a relational db, but it will scale much better.

Failure scenarios/bottlenecks

The casandra transaction is evetnualy consistent, so it's pposible the tables wont' be in sync for a a berife periold of time. We could create duplcate mappings for a given url if that happens.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?