// case study · performance testing · cloud platform
Finding the bottleneck before a critical period of demand.
A UK organisation relied on a cloud-based platform for public transactions and time-sensitive operational work. Following an earlier service disruption, it needed evidence that the platform could handle its next period of peak demand and a clear plan for reducing risk.
// at a glance
- Challenge
- Uncertain capacity after a previous outage, with no remaining monitoring evidence to confirm the cause.
- Work
- Realistic load, stress and spike testing across public and operational user journeys in a protected test environment.
- Outcome
- Peak capacity verified, two different bottlenecks identified and a practical plan agreed for infrastructure, code and monitoring.
// the outcome
- A clear statement of the demand the platform had safely demonstrated.
- Evidence that the database, not the web application tier, constrained the public journey.
- A repeatable peak-capacity plan based on measured behaviour rather than guesswork.
- A separate code and data-access bottleneck identified in the operational workflow.
- Prioritised engineering recommendations, monitoring thresholds and operating precautions.
- Reusable scripts, test data controls and safety measures for future regression testing.
The challenge
The platform supported complete customer journeys, including data entry, transactions and confirmation, as well as operational workflows used by distributed teams during concentrated periods of activity.
An earlier outage had damaged confidence, but the historic telemetry needed to diagnose it was no longer available. The organisation did not simply need more hosting capacity. It needed to know what the platform could safely handle, what would constrain it first and where investment would make a meaningful difference.
Testing also had to avoid production, protect customer information and prevent real calls to payment, messaging, location and other chargeable external services.
Building a safe and realistic test
DevStack began with evidence. We reviewed historic demand in aggregate, mapped the complete journeys and translated actual usage patterns into normal, peak, growth and sudden-burst scenarios.
A dedicated load-test mode replaced external services with controlled substitutes that behaved realistically without sending messages, taking payments or consuming third-party credits. Multiple safeguards prevented the test tooling from running against the production service.
The test scripts reproduced complete journeys with realistic pauses and a representative mix of activity. We first ran against a local copy, then moved to an isolated cloud test environment. Demand increased in controlled steps, with response times and errors matched against application logs, cloud metrics and database utilisation after every run.
Testing the public journey
The first phase established how the public transaction journey behaved at the recorded peak, above the recorded peak and at the organisation’s agreed extreme burst target.
- The platform completed the recorded peak and a test at more than five times that level without failed requests.
- At the extreme burst target, the existing database reached its limit while application compute remained lightly used.
- The evidence showed that adding more web-server capacity would not solve the problem. The constraint was the database tier.
- After database capacity was adjusted, the identical burst completed without failures and the critical transaction remained below one second at the 95th percentile.
This gave the organisation a defensible capacity plan. It could scale the component that mattered before known peaks without paying to overprovision the rest of the platform.
Testing the operational workflow
The second phase examined an internal and mobile workflow used by operational teams at the busiest point in the service cycle. Individual screens appeared acceptable with a handful of users, but performance deteriorated sharply when the full operation was simulated.
The database again reached saturation, but this time infrastructure alone was not the real answer. Application tracing showed that each request loaded the entire operational dataset before discarding almost all of it. A summary screen also transferred far more data than the user needed on every refresh.
DevStack identified the code-level cause, the concurrency level at which the current design became unsafe and the specific queries and endpoints that needed redesigning. Temporary capacity guidance reduced immediate risk while the permanent fix could be planned.
The outcome
The organisation entered its critical period with evidence about capacity, a proportionate infrastructure plan and clear monitoring in place. Early live-service data aligned with the test findings and showed comfortable headroom under normal demand.
Just as importantly, the engagement separated two different problems. One required temporary database capacity for an extreme public burst. The other required a targeted software change so operational screens stopped reading far more data than they needed. Treating both as a generic hosting problem would have increased cost without removing the underlying risk.
Need to know what your platform can handle?
DevStack provides independent load and performance testing for websites, applications, APIs and cloud platforms. We reproduce real journeys, find the limiting component and turn the evidence into a practical capacity and remediation plan.