Performance and Load Testing

Performance and load testing checks whether a system can handle the volume, speed, and concurrency it will face in real use, without slowing to the point where the service effectively stops. A system may work perfectly for a small number of users and still fail when thousands try to use it at once: queues grow, response times lengthen, a database locks, or a third party service throttles requests. For a financial service, slowness is not a minor inconvenience. If customers cannot pay, trade, or access funds when they need to, the function has failed, even if no component has technically crashed. Load testing finds that point of failure in advance, under controlled conditions.

Load is not a single number. It includes how many users act at once, how many transactions arrive in a short burst, how large the data sets are, and how the pattern changes over a day. A tax payment deadline, a market opening, or the end of a month can each create a different shape of demand. A payroll service, for example, may be quiet for most of a month and then face a concentrated surge as employers submit payments together. Testing should reproduce the shapes that matter for that service, including bursts and sustained peaks, rather than a steady average that never occurs in practice. An average load test can pass while the real peak still breaks the service.

Systems rarely fail alone. Under load, a slow supplier response can cascade: the firm's system waits, its own queues grow, and customers retry, adding still more load. A fraud checking service, an identity verification provider, or a payment rail may each have limits that only appear at volume. Load testing should therefore include those dependencies, or reproduce their behaviour faithfully, and should observe what happens when one of them slows rather than fails outright. A system that copes with a clean failure, by switching to a fallback, may cope badly with a slow response, because it keeps waiting and never switches. That distinction is a common load testing discovery.

Failure in load testing is defined before the test begins, in terms of the service customers experience: response times beyond which customers abandon the service, transactions that time out, or queues that do not drain. Without that definition, a test can be declared a pass because the system stayed up, even though customers would have experienced it as unavailable. Observers should watch the whole chain, from the customer channel through processing to settlement or confirmation, because a bottleneck in one place can look like a failure somewhere else. The record should show where the bottleneck sat, what caused it, and at what level of demand it appeared.

Here again, the laboratory pitfall is central. A test environment with smaller data, faster storage, or fewer competing services may handle a load that production cannot. Conversely, a test environment that is much weaker than production may produce alarming results that do not reflect the live service. Either way, the test tells the firm about the wrong system. Where possible, load tests should use production-like data volumes and configurations, with safeguards for live customers, and the report should state how the test environment differed from production. A load result without that comparison is difficult to trust, however impressive the numbers in the report may appear.

A load test that finds a bottleneck should lead to a concrete change: capacity increased, a queue redesigned, a retry pattern corrected, a supplier limit renegotiated, or a degradation plan prepared for the moment when demand exceeds capacity. That plan matters, because no system can be built for unlimited demand. Knowing what the firm will do when load exceeds the tested level, such as queuing fairly, informing customers, or prioritising critical transactions, is part of resilience. The follow up load test should then confirm the change, at the level where the bottleneck previously appeared, rather than at a comfortable level below it.