Capacity estimation

100.000 daily users, with an average of 2 shorten requests each. 200.000 requests daily for shortening processes.

For the same amount of users, we will assume they will navigate shortened links 10 times per day as a baseline (1.000.000 daily requests). It is expected that each user will do more parsing requests than shortening ones.

Each shortened url can be created with a maximum of 25 characters (25 bits). A full url, we can allow up to 100 characters (100 bits). That gives us:

25 bits per shortened url at 1.000.000 requests = 3.2 mb daily in queries. 100 bits per full url at 1.000.000 responses to those requests = 12.5 mb daily in responses. 15.7 mb in navigation requests daily, 0.00018 mb per second.
For creating a new shortened url we use a fraction of that, as there are 10 navigation requests per 2 url shortening ones. 15.7 mb / 5 = 3.14 mb per day, 0.000036 mb per second.

For storage of these, we are looking at 15.7 mb daily for parsing requests + 3.14 mb for url shortening requests = 18.84 MB daily. Multiplying that by 30 days, we've got 565.2 MB per month in url storage.

Anticipating annual growth of 25% we've got:

565.2 mb per month on the first year = 6.8 gigabytes
Increase of 25% for the following year = 6.8 + 25% (1.7) = 8.5 Gigabytes on year two.
6.8 + 8.5 = 15.3 gigabytes

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10