The goal is to understand how much traffic will hit the API during its first weeks and how fast are we anticipating the traffic to grow. The idea is to use the Minimum Viable Architecture approach so we design and build only as robust architecture as we need right now so we can optimize the work, schedule, complexity, and cost. But we also need to understand the current need of how soon to scale up, so we are able to measure, analyze and decide when more planning and re-designing the architecture is possibly needed.
Draw the scale and estimated amounts vs. calendar time to the template, using business measures such as the number of orders coming in or the number of customers created, updated or search:
New orders in a month
It is much easier to estimate how many boxes will be shipped than how many API requests are going to be done in one day. The business people know the answer to the first, and the rest is maths. This way we use business measures in this method. This way it’s possible to estimate also bandwidth and storage needs. You just need to understand how big an amount of data is involved in each order. Then multiply at least by x 3 to get the amount of data transferred in the requests.
If there is an existing solution, ask about any visitor statistics about it. This may be useful as a baseline for future usage. Ask about any plans to do big campaigns or product launches. Or any changes to the process, business model, etc. These may cause much more or less traffic than before.
Try to get some tangible measures, for example how many orders are coming in each month? Are there any peak days or times when lots of customers, customer service, or some other group of users would be more active than others? Are the API Consuming services “open for business” every day, all day?
If no one has data about how much traffic there is in a minute or second, try to use the monthly data to calculate the maximum peak in minute and second. These measures are important for setting rate limits to APIs and API consumers so one API consumer is not easily able to overload the whole system. It’s also important for planning capacity for API gateway, firewalls, and other network components and estimating impact on backend systems.