I am developing a backend where in I will be exposing APIs for my mobile application. Users can register,add products,share the links of products through email/sms/anywhere and others can click on it and buy the product. This is the simple workflow of the mobile application. The app is an image intensive app which will have image uploads and retrieval which will be done by third party cloud service. SO the image part is not handled by my backend.

Now I am from the development team and have little experience on hardware server side. When I gave the requirement for the infrastructure, they have given asked me the following questions.

  1. Application/Storage Throughput
  2. Application throughput (No. of concurrent connections in 3 months , 6 months and 1 year)
  3. Storage throughput (Data growth in 3 months , 6 months and 1 year)
  4. HA requirement
  5. DR requirement

I am not sure how do I forecast the above 3 points. How are through puts calculated? I will on an estimate will be having 10000 users registering on my application in the first month out of which 5000 will be active users. On an average login to application there will be 10 API hits per user which will lead to 5000*10 = 50,000 hits per month which would be 1 API hit per minute,ie ~2 concurrent connections in first month.

Is the calculation goes like this? and how do I calculate the data growth ? Does it mean, a user registers,creates product and if I total the database size consumed for that, is that what is called data growth?

This question would seem pathetic, but I genuinely need help in figuring out how throughputs are calculated for server requirements.

3 Answers 3


The first three points are capacity planning. The organization is trying to budget and predict for the future. Alas, there is no simple or accepted way to predict performance and scalability. Each application and environment is different. Therefore, the best way to answer this is to measure.


  1. Discuss with your management or product owners what the likely growth in users will be and the types of different users. If they do not know, guess but document that these are guesses.
  2. Create an automated run through of common paths of your application. You can record activity or enter your own into load testing applications like JMeter.
  3. Create a test environment that matches your current or projected hardware. Pay close attention to things like bandwidth, storage, SSL, logging or other frequently forgotten aspects that could affect performance. Mock out the third party image service if you can, using smaller or representative images.
  4. Use the load testing application to create the proposed for the projected numbers of users at different times.
  5. Use an application performance management tool, like AppDynamics or DynaTrace, to measure performance and identify bottlenecks.

In addition to above requirements, this can help you:

  1. Confirm your environment supports the requested load.
  2. Find the maximum load your environment supports.
  3. Find the bottleneck(s) limiting your performance or scalability.
  4. Experiment with different configurations to see how the perform or scale.
  5. Observe how the system copes when you trigger failures.

The last two points, HA requirement (high availability) and DR (disaster recovery, presumably RPO (recovery point objective) and RTO (recovery time objective)), are harder to predict as these are really business requirements. Discuss with your management or product owners the likely failures and how much they will cost to mitigate or fix. If both of you are new to this, expect lots of guessing and late nights on your part.


I would propose a more objective basis. Go to your existing HTTP logs. Assuming this is an update to an already in the field app, simply pull the logs and examine the HTTP requests which are included. This provides an absolute objective basis fore your load modeling instead of a wetted finger in the air to test the wind.

Also, keep in mind from a QA perspective. You cannot both own the requirement and the validation. So, you can use the objective data from the logs to help build the load model informatiuon, but someone in the business needs to sign off on the actual definition. Why? Because you are injecting a requirement in the stream which heretofore has not been available to the developers, the architects, the platform managers, etc... if you fail the app, you want the business behind you that the numbers are accurate.

What can you pull the logs?

  • Highest transaction rate per hour (count requests blocked by hour)
  • Highest users per hour (count IP address blocked by hour)
  • User Data flows ( See referer tag on requests to build a tree of previous requests)
  • Existing response times ( if you have the w3c time-taken field enabled for your web services calls ). This can be used to set expectations for future releases on an objective basis for hitting or exceeding the current model
  • Think times from the delays between requests by IP. You can actual model the sample points on the time between any two requests by grabbing the referer tag and blocking by IP address to build a sample set. You can then pull stats on those samples for min, max, average, 90th percentile think times. Heck, some stats packages will even provide you with a function that you can insert a random number in to get a distribution appropriate to production
  • If you have logs for previous time periods you can project growth models for observed versus desired (sales or use projections )

I prefer Splunk for this type of work. For most organizations you should be able to pull 30 days worth of logs into the free tier without having to worry about setting up a half a dozen different apps together like you do with the ELK stack.

Get the requirements wrong and you may well be chasing engineering ghosts that would never occur in production and not actually reduce any risk. Make sure someone in the business side signs off on your requirements or you could well own individually budget overages for chasing non defects.


I really like your question. Its a good one. I dont think there is a real answer to this but I will try. When creating/designing a new Server its most important to choose the right
Enviroment and Methods. Not all Enviroments are scalabale, most only in a limited way. What the Hardware-Team is trying to calculate is, what type of filesystems and Interfaces they can use. Some fileystems are easy to setup but hard to expand. Others are hard to setup but easy to manage and expand.

Best thing in my opinion is, to get in touch with the ones asking you these Questions and explain them why you cant answer these right now. When launching a new Application or System noone can say how this all evolves especially when there are no other System you can compare to. But you have the knowlegde about the API you designed and the "Hardware-Man" has the knowlegde how his Enviroments /Servers work. Together you can figure this questions out for sure.

Hope this helps you.

  • 1
    What exactly do you mean by "Environments and Methods"? Can you give an example of a scalable environment? And by "Methods", do you mean backup method, authentication method, etc., or something else?
    – Jay Elston
    Feb 24, 2016 at 1:38
  • @JayElston By Enviroment and Methods I mean the right choice of Server Architecture. Some smaller Applications use one Server to run the Application and to store Data. Some bigger Applications cant do that because they need more Space for Data. By Methods you have to think about all those things. Speaking about scalability Virtual Server are a good thing. But keep in mind: adding RAM or more Space does solve Problems for a short time, but its not a general Solution. Also you have to different horizontal and vertical scaling. See here: en.wikipedia.org/wiki/Scalability Feb 24, 2016 at 9:16