Loading...
should handle lots of data
will support many more reads than writes.
should track number of times each link is clicked
The system should reflect updates to tiny urls with in 30 seconds with a SLA of99.999%
The system should return redirect reads with in 10 milliseconds.
List non-functional requirements for the system...
Immeiate consistencey
don't need to plan for loosing an entire region.
1 trillion shortened urls
1 million read requests per second
1000 write requests per second
create alias will flow to the nearest region that the system is deployed to.
look up alias - will first hit the CDN, if there's a cache miss, it'll inspect the url and forward it to the region that own's the particualr tiny url.
delete alias - the CDN will route request to the deployment that owns the given tiny url.
update won't be supported
Casandra
Add a table
short_to_full
shortended url -> full length url, is_visable
full_to_short
full url-> short url
Read requests will flow from CloudFront into to casanda on cache misses. CloudFront will have a ttl of 10 minutes for cache entries. CloudFront will aggregate url hits and send them to the service in bunchs every 10 minutes. The service will save those to casandra.
This ensures that Casandra always anaytics data that's no more than 10 minutes out of date.
Casandra records have a ttl of 6 months. Updates, or analtyics dumps to the records refresh this ttl back to 6 months. So if a record is untouched for 6 months's it's delted.
On deltes, the service will reach out to cloudfront to delete the cached entry.
The service will be deployed to 3 AZs per rregion. This ensures that the data will be persisted if we loose up to 1 AZ at a time.
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 8 base 64 charaters long. This supports over 2 trillion entries.
Each region will own a slice of the address space to hand out urls for. This ensure that no cross region coordiaation is necessary.
I'd deploy the app to sevral regions around the globe. Each region would own a subset of the url address space. I'd have 3 replicas for each entry. I'd do quorum writes the 3 nodes on updates, and I'd do single node reads on read reqeusts.
A no sql db is harder to work with than using a relational db, but it will scale much better. the CDN will be out of sync with Casandra for a maxof a few minteus.
A deleted entry will remain live in the CDN for a few minutes as the cache purge is carried out.
I'd partition the services globally to own a differetn range of the url space that it can give out new urls for. this would ensure that a given AZ would be able to independntyly decide if a url is free without contacting other AZs.