This time, the owner wanted the system prepared to handle 20,000 transactions per second. At the same time, one condition was firm: no further investment in changing the application code.
The owner was prepared to fund substantial cloud infrastructure but had limited experience with cloud pricing. Our responsibility was therefore not simply to implement the requested capacity. It was to determine what the business actually needed at launch.
Find a workable path for the legacy system
The application's age and design made a container-based deployment on services such as AWS Fargate impractical without code and packaging work. Given the no-code-change constraint, we selected an Amazon EC2 deployment with a managed MySQL database as the most practical route.
Using previous benchmark results as a reference, we ran load tests to evaluate the proposed architecture. The tests indicated that a sufficiently large configuration could support the modelled target under the tested conditions.
That did not mean purchasing maximum capacity immediately was a sound business decision.
Scale from evidence, not ambition
Provisioning infrastructure for 20,000 transactions per second from the first day would have created a large recurring cost before the product had proven demand.
We recommended starting with a smaller configuration capable of handling realistic early traffic. Resource usage would then be monitored, and the EC2 and database capacity could be increased in planned stages as demand approached agreed thresholds.
We estimated the infrastructure cost for each proposed stage using AWS Pricing Calculator. The configurations, pricing assumptions, and estimated costs were documented and shared with the owner, making the financial trade-offs transparent before any resources were purchased. These figures were treated as planning estimates because actual charges would depend on usage and other billing factors.
The legacy application had not been designed for automatic horizontal scaling, so this was a controlled vertical-scaling strategy. Each increase would require operational planning and could involve a service interruption, particularly when changing the database instance.
CloudWatch resource alarms and cost alerts were configured to provide early warning of unusual utilization or spending. We also defined the conditions that would trigger a review and the next infrastructure increase.
The outcome
The owner agreed to the staged approach. After relaunch, initial traffic remained low—as is common for a product rebuilding its market.
Had the largest infrastructure configuration been purchased from the beginning, most of that capacity would have remained unused while generating substantial cloud charges. Starting smaller avoided that unnecessary expense without preventing the system from growing when genuine demand appeared.
The practical lesson is simple: technical capacity should follow measured business demand. A large theoretical target may be useful for planning and testing, but it should not automatically become the first production bill.