A growth launch can justify more infrastructure before it justifies a different architecture. The difficult decision is where the first investment belongs: a slow query, a larger database, another application instance, or a change to when expensive work runs.
Start by testing the work the launch will create. A useful result connects demand to completed business actions, shows where performance first deteriorates, and identifies a change that improves that limit. A headline user count cannot do that. Neither can an API that accepts every request while its unfinished work accumulates.
Turn the growth forecast into a workload
A forecast of 10x growth needs a unit: ten times as many accounts, requests, stored records or exports. Those are different workloads. Translate the forecast into the busiest period the business needs to support. Specify who is active, which actions they perform, how frequently they repeat them, and what background work overlaps. Include the expected data volume: searching a small trial account and exporting several years of records are different demands. Microsoft’s capacity-planning guidance connects these workload characteristics to demand scenarios.
Consider a hypothetical operations portal with 1,000 registered staff accounts. In one scenario, 200 people each retrieve a work list once a minute: roughly 200 list requests per minute, before other activity. In another, the same 200 people each refresh six times a minute: 1,200 requests per minute. Both have the same user count. If scheduled exports start at the same time, the interactive traffic must also compete with those jobs.
The scenario therefore needs more than a concurrency setting. Record the mix of reads and updates, export frequency and size, arrival pattern, and duration of the busy period. Separate observed behaviour from forecast assumptions so the team knows which uncertainty the test is addressing.
Define success at the point where work is useful
For the portal, list retrieval ends when the correct records appear. An update ends when the change is saved. An export ends when the complete file is available to its intended user. A successful submission response establishes only that the system accepted the job.
Agree targets for these outcomes before comparing infrastructure options. As illustrative targets, the portal team might require 95% of list views to finish within two seconds and scheduled exports to be available within fifteen minutes. These figures are arbitrary examples, not benchmarks; actual targets should follow staff needs and reporting deadlines. Define acceptable failure rates and check correctness alongside speed.
Measure the slower portion of responses, not only the average. Track latency by operation, errors, traffic and resource saturation, following the distinctions in Google’s monitoring guidance. For exports, add completion rate and the age of unfinished jobs. A dashboard dominated by fast list requests can conceal a small number of seriously delayed updates.
Test the collision before buying capacity
In the hypothetical portal, begin with interactive activity alone, then exports alone, then the planned overlap. Use comparable data and infrastructure across runs. This separates a generally slow application from a problem caused by competing work.
Suppose the interactive test meets its targets. During the combined run, list latency rises and exports miss their deadline. Application CPU remains moderate, while database reads increase sharply. That makes database work a candidate for investigation. Check query duration, database waits and storage throughput before choosing more web instances; additional web capacity will not resolve a confirmed database bottleneck, as Microsoft’s scale-out guidance explains.
A query execution plan can show how records are scanned, joined and sorted; PostgreSQL’s documentation explains how to inspect those plans. The goal is to identify avoidable work before selecting a remedy, rather than treating every slow query as an indexing problem.
Suppose the export repeatedly reads records outside its required reporting period. Narrowing that query becomes the first candidate change. Repeat the combined test with the same workload. If it now meets both targets at the expected data volume, the evidence supports postponing a larger database. If the query is necessary and efficient but storage throughput remains exhausted, a capacity increase becomes a stronger candidate.
These hypothetical findings narrow the options; they do not set the budget. If both a capacity increase and a query change meet the targets, compare implementation and verification time, launch risk, ongoing cost and reversibility. A temporary capacity increase may be the practical launch choice when a code change cannot be checked safely in time. Give that temporary spend an owner and a review trigger.
Choose the next change from the evidence
| Change | Evidence and checks |
|---|---|
| Tune | When repeated or unnecessary work dominates. Verify the complete workflow afterward; a faster query that changes the result is a defect. |
| Resize | When an appropriate resource is consistently limiting useful throughput. Compare the added cost and capacity, including the next likely limit. |
| Scale out | When application capacity is the constraint and requests can safely run across instances. Session state and shared dependencies need to support that arrangement. |
| Isolate expensive work | When exports interfere with interactive requests. Separate workers can control scheduling and concurrency, but shared database pressure still needs a limit. |
| Defer | When the tested launch scenarios meet their targets and no current constraint justifies the proposed change. Set a measurable trigger for reconsidering it. |
A queue changes when work finishes
Moving exports to a queue can keep users from waiting on an open request and let workers control pressure on the database. It also creates a new waiting place that must be measured.
For an illustrative calculation, assume an empty queue receives 60 similar export jobs in a short burst, and workers sustain six completions per minute while interactive targets remain satisfied. With no further arrivals, the batch takes about ten minutes to drain, within the illustrative fifteen-minute deadline. If ten jobs arrive every minute while only six finish, unfinished work instead grows by four jobs per minute. Over a sustained busy period, that backlog can push completion beyond the deadline even while new submissions receive fast acknowledgements.
Microsoft’s queue-based load-leveling guidance describes this limit. Worker concurrency must protect downstream resources. Durable storage, duplicate-safe processing and a route for failed jobs are also necessary. Test whether exports complete within their deadline and whether the queue drains after a burst.
If the deadline fails, the next choice is concrete: reduce export work, move the schedule where the business permits, or increase the constrained processing capacity. Adding consumers is useful only if the downstream system can support them.
Make the test strong enough for the launch decision
Use a production-like environment with representative data sizes, access patterns and dependency behaviour. Record differences that limit the conclusion. A small database with a warm cache cannot establish how a much larger dataset will behave. Microsoft’s performance-testing guidance recommends matching test scope to workload risk and defining explicit acceptance criteria.
Begin at ordinary demand and increase it progressively. Test the forecast peak, a credible burst, and a sustained busy period long enough to expose accumulating work. Keep the scope focused on the launch’s critical workflows. Check that the load generator produces the intended arrival rate even as the application slows; otherwise the test may quietly reduce demand at the point that matters. Grafana explains this distinction in its guide to open and closed load models.
If the launch depends on autoscaling, measure how long new capacity takes to become usable and whether targets hold during that delay. Check quotas and downstream limits as well as the configured instance maximum. Microsoft’s autoscaling guidance explains why startup time and available capacity belong in the test.
Keep generated load within an agreed test boundary. Use controlled dependency simulations where appropriate, and record what they leave untested. Production systems and third-party APIs need explicit limits and coordination before receiving test traffic. Define stop conditions and a recovery owner before the run.
Include behaviour near the limit. The portal might pause new exports while preserving updates, or explicitly reject work it cannot finish. Check recovery after traffic falls. Retries deserve attention: they add load, and a timeout does not prove that an update failed. AWS’s retry guidance explains why duplicate-safe operations, bounded retries and backoff with jitter matter.
Approve a bounded change and a way to verify it
The spending decision should name the tested workload, the change being funded, the targets it met, and why its delivery risk and continuing cost fit the launch. For exports, compare cost per successfully completed job at the agreed workload, alongside completion time. A cheaper run that leaves jobs unfinished is not an equivalent service.
Assign someone to monitor the launch, define when to halt further rollout, and prepare a rollback or recovery path appropriate to the change. A passed test supports the conditions tested. New data volumes, heavier workflows, dependency changes or a different arrival pattern can require another run. Set capacity margin from those uncertainties and the time needed to respond.
LegioSoft can help scope the application and cloud changes indicated by the evidence, with verification against an agreed workload. The work and estimate depend on your system and growth scenario. Tell us which workflow must handle more demand and what is changing in the next launch; that gives the conversation a concrete starting point.
