Shor10 (or short10?) Basically, a url shortener
Actions
(User side)
Shorten a url:
User writes a url in the url field
User clicks on 'Shorten url'
A short url is generated and displayed to the user
Access a short url
User inputs his short url in his browser
User gets redirected to the long url that got shorten in this short url
Actions
(Backend)
Shorten a url
Input: long url
The long url is
hashed using md5
The hexdigest is retrieved and converted to base10
The base 10 is converted to
base62
The result is truncated to a
short url
(7 characters)
Check if this url is already stored (cache then dynamodb), and links to the correct long url
Handles
collisions
if needed
If not,
stores the link between short/long
Output:
short url
Access a shorturl
Input the short url
Tries to find the url in the db (Cache then dynamodb)
Ouput the long url
Architecture
Base
Note that redis could have been replaced by DAX
Scaling
'Simplified' overview of the current architecture
Improvements
What could be changed?
Secondary index
on dynamodb
Url sanitizing
(removing `https`... blocks)
Currently dynamodb is not set up to scale automatically but could easily be (for simplicity and costs limitation)
More cloud watch alarms could be set up for auto scaling policies, and not on cluster CPU but instances CPU or others
Using elastic cache, or DAX
The way to production
Having a more secure architecture (Not have public IPs on instances, bastion host for ssh or VPN...)
Avoiding single point of failure on ELB
Stress tests, study the cost of the solution
Fully automated deployment
Terraform: create test/prod environments
Terraform the fact of adding ELB records to the main hosted zone
How many reads compared to writes? Maybe scaling read functionality in another service is better.
Questions time!
Made with Slides.com