You assess application scalability by measuring an end-to-end business scenario under the load you actually expect, then identifying the resource or serial point that limits it. More servers will not solve a locked database row, a serial calculation, a slow external API, or a message queue that grows faster than its consumer can drain it. The aim is not a good-looking test result, but evidence of system capacity and of what happens when that capacity is exceeded.
Average user numbers rarely describe actual load well enough. For a business application, what matters more is what users do at the same time, which data they work with, and at which point in the working day.
Month-end closing, morning production entry, issuing a large number of documents, or mass calculation can have a very different profile from ordinary work. One process may mainly read data, while another simultaneously creates many writes, locks, and background jobs.
That is why the starting question is not "How many users can the system handle?" A more useful question is: "Can the system complete the work that users must complete at peak time?"
For every important scenario, describe:
This description turns a vague request for more capacity into a testable decision. For example, it is not enough to say that a report must be fast. You need to determine whether an interactive production-entry confirmation may wait while a mass report is running, and what happens if both processes use the same resource.
Load testing is useful only when test traffic resembles the work you expect. A test that sends a large number of identical GET requests may show good latency while missing a problem in writes, queue processing, or a synchronous call to an external service.
The load model does not need to be complex at first, but it must include real ratios and the sequence of actions. If most users enter data at peak time while a smaller group reviews status, the test must include both flows. If an entry triggers a calculation or a message for another application, that follow-on step must not be excluded.
It is useful to run the test in three phases:
This last phase often distinguishes a temporary slowdown from a problem that continues to block work after peak traffic has passed.
A slow response is a symptom, not a diagnosis. Latency may rise because the processor is busy, memory is under pressure, database connections have reached a limit, storage is slow, the network is congested, or an external service limits calls. In business systems, locking is also a common cause: multiple processes wait for the same data or the same processing sequence.
During load testing, track at least these indicators:
Percentiles matter because an average can hide the experience of a smaller but business-critical share of requests. If most confirmations complete quickly but some wait unacceptably long, a user who must re-enter data or misses a deadline will not experience the system as responsive.
Connect a request through tracing, from user action to database, queue, and external call. Only then can you see where time actually disappears. A metric may show growing wait time, while a trace can confirm whether the application is waiting for the database, a queue consumer, or an external dependency.
Adding application instances helps only when work can be distributed. If the whole flow passes through a global lock, a shared session, one queue consumer, or one serial calculation, additional instances may increase contention for the same limited resource.
Before changing infrastructure, check whether a serial point exists. Decision questions can be straightforward:
The answer is sometimes not more capacity, but an algorithm change, batched writes, removal of unnecessary coordination, or asynchronous processing. A cache can reduce read load, but it introduces the question of stale data. Asynchronous processing can reduce user wait time, but it requires clear processing status and a way to handle errors. Every optimisation has a business consequence that should be understood before implementation.
For processes that span several functions, it is particularly important to observe the whole flow. Business modules connected to ERP can share data and dependencies, so making one screen faster may not remove the bottleneck in the next step.
For each scenario, record the same items before and after the test. This avoids optimising based on an impression or on one isolated metric.
This sequence prevents the false conclusion that a change helped merely because the test was different. It also preserves the connection between a technical metric and a business decision: which action must remain available and which may wait.
Every system has a capacity limit. What matters is that crossing the limit is predictable. Uncontrolled waiting can occupy all worker threads or database connections and turn a local slowdown into a full outage.
Backpressure, queue limits, rate limiting, and timely timeouts can help the system reject, defer, or schedule work in a controlled way. However, the business layer must define priorities. An interactive user confirmation may not be allowed to wait behind a mass report, while the report can be deferred or processed in the background.
Users need an honest response. It is better to clearly show that processing is waiting and preserve the request where appropriate than to leave a screen loading indefinitely, encouraging repeated clicks and creating additional load.
There are real tradeoffs here. A larger queue may temporarily protect the application, but it increases wait time and the risk of pending messages. A shorter timeout may release resources sooner, but it may interrupt a process that would otherwise complete. Limits and priorities should therefore follow from the business scenario, not only from technical default values.
One successful test is not a permanent confirmation of scalability. Data grows, functions change, usage patterns shift, and external dependencies gain new limits. The cost of scaling also needs to be monitored. A system that reaches its target only at an unsustainable cost is not resolved in a sustainable way.
Set thresholds that warn before saturation, assign ownership for monitoring them, and repeat relevant scenarios after significant changes. This is especially useful when production, accounting, and integration processes are connected in connected operations , where changing one flow can alter the load on another.
If it is unclear which scenario to test or where measurement should begin, ERP and process screening can help structure processes, dependencies, and decisions before a larger change. ORKA performance review connects the business scenario, load test, observability, and architectural decision so that capacity is assessed through evidence of where the system actually stops keeping up with the work.