System requirements

Functional:

should handle lots of data

will support many more reads than writes.

should track number of times each link is clicked

Non-Functional:

List non-functional requirements for the system...

Immeiate consistencey

Capacity estimation

1 trillion shortened urls

1 million read requests per second

1000 write requests per second

API design

create alias

look up alias

delete alias

update won't be supported

Database design

Casandra

Add a table

short to count

short url to times visited

short_to_full

shortended url -> full length url, is_visable

full_to_short

full url-> short url

Redis

short url to full url , click count.

High-level design

non-read requests will be enqueued in Kafka for futehr processing. Once in Kafa, the server will read them back out and update them in casandra and redis.

Read requests will flow into redis first ( cache), if there's no data there, it will fallback to casanda.

Writing kafka instead of casanda and redis directly, ensures that both will eventually be consistent

Redis will operate as a cache for Casandra. Before an entry is removd from the cache, the analytics will be written to Cassandra .

Url generation

tiny urls will be randomly genrated. if a new url already exists in Casandra, the system will generate a new url and try the process again. once sucessfully, it will return the new url to the user.

the url will be 11 hex charaters long. This supports over 2 trillion entries.

Trade offs/Tech choices

A no sql db is harder to work with than using a relational db, but it will scale much better. Redis and Casandra may be out of sync for a bit while the data is sorted otu by the stem.

Future improvements

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