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.