Performance and Scalability

Performance and scalability are often discussed together, but they describe different problems. Performance is about how quickly a system responds under current conditions. Scalability is about whether that response time holds up as the number of users, records or transactions grows. A system can be fast with fifty users and collapse at five hundred. Understanding both concepts helps you ask the right questions during development, set realistic expectations with suppliers and avoid costly surprises after launch.

How to Plan for Web Application Performance

Planning for performance starts long before any code is written. It begins with understanding what "fast enough" means for your specific users and processes. A CRM that takes two seconds to load a customer record may be acceptable if it replaces a five-minute phone call, but a portal where customers submit payment details will have a much tighter tolerance.

The practical starting point is to define response-time expectations for the system's core actions: logging in, loading a dashboard, running a search, submitting a form, generating a report. Write these down as measurable targets rather than vague aspirations. A statement such as "the customer search should return results within two seconds for up to two hundred concurrent users" gives a developer something concrete to design around.

You also need to consider where your users are. A system that feels responsive when tested from an office in Manchester may behave differently for remote workers in Scotland or a client in Singapore. Network latency is not something the application code can eliminate, but the architecture can mitigate it through choices about where servers are located and how much data each page request transfers.

Common mistakes at this stage include leaving performance as an afterthought, setting no measurable targets at all, or demanding sub-second response times for operations that inherently involve processing large volumes of data. The last of these often leads to over-engineering and unnecessary cost. Be specific about which actions genuinely need to be fast and which can tolerate a short delay.

Questions to put to a supplier

• What response-time targets are you designing for, and for which specific actions?
• How will you measure performance during development?
• What happens to those targets if the data volume doubles in year two?
• Where will the application be hosted, and does that location affect user experience in our key regions?

Load Testing: What a Business Should Know

Load testing means simulating real usage patterns at scale to see how the system behaves before real users encounter problems. It is distinct from functional testing, which checks whether a feature works correctly for a single user. Load testing checks whether that feature still works when dozens or hundreds of users do the same thing at the same time.

There are several varieties worth understanding, even if the technical execution is handled by your development team. A baseline load test replicates your expected normal traffic. A stress test pushes beyond that level to find the point where performance degrades or the system fails. A soak test runs normal traffic over an extended period, often hours or days, to expose problems that only appear over time, such as memory leaks or database connection exhaustion.

What matters from a business perspective is not the tool being used but the scenario being tested. A load test that sends five hundred simultaneous login requests tells you very little if your actual usage pattern involves a steady flow of logins spread across the morning, followed by a midday spike in report generation. The test scenario should reflect real behaviour, not an artificial worst case that never occurs in practice.

Ask to see the test plan before it runs. It should specify the number of simulated users, the mix of actions they perform, the duration of the test and the pass/fail criteria. After the test, the results should show not just whether the system survived but how response times changed under load. A system that passes but slows from one second to eight seconds under normal peak traffic may need attention even if it did not crash.

Practical checks

• Review the test scenario to confirm it matches your actual usage patterns, not a generic template.
• Ensure the test includes the specific reports, searches and workflows your team relies on most heavily.
• Ask whether the test environment mirrors production closely enough for the results to be meaningful.
• Request a written summary of findings, including any degradation observed and recommended remedies.

Capacity Planning for Web Applications

Capacity planning is the process of estimating the resources your application will need as it grows, and putting provisions in place before those resources are exhausted. It applies to server infrastructure, database storage, bandwidth and any third-party services with usage limits or per-transaction costs.

The starting point is your current baseline: how many users, how many records, how many transactions per day or month. From there, you need a realistic growth projection. This does not require a precise forecast, but it does require an honest conversation about what growth would look like under different scenarios: steady organic increase, a new product launch, onboarding a large client, or seasonal peaks.

For infrastructure, the key question is whether your hosting arrangement can scale. Some environments allow you to add server capacity with minimal configuration changes. Others require manual intervention, new provisioning or even architectural changes to add more servers. Understanding this distinction matters because it determines how quickly you can respond to growth.

Database capacity is frequently underestimated. A system that starts with ten thousand customer records may seem fast, but if that figure grows to two million over three years, queries that were once efficient can become slow unless the database is designed with that growth in mind. Indexing strategies, data archiving and partitioning are technical decisions, but the business input they require is straightforward: how much data will the system hold, how fast will it grow, and how far back must records remain instantly searchable?

Third-party services deserve particular attention. If your application relies on an external API for pricing lookups, address validation or document generation, check whether that service has per-call limits, tiered pricing or throughput caps. A bottleneck in a dependency outside your control can constrain your entire system.

How Caching Improves Web Application Performance

Caching is a technique for storing the result of an expensive operation so it does not need to be repeated every time. In a web application context, "expensive" usually means a database query, a calculation or a request to an external service. If the result does not change frequently, serving it from a cache instead of regenerating it each time can reduce response times dramatically.

There are different levels at which caching operates. Page-level caching stores an entire rendered page, which is effective for content that looks identical to every user. Fragment caching stores parts of a page, such as a navigation menu or a product category list, while allowing other parts to be generated dynamically. Data-level caching stores the results of specific queries or calculations, which the application can then use across multiple pages or processes.

The trade-off with caching is freshness. A cached result is, by definition, slightly stale. If a customer updates their address and the old address is served from a cache for five minutes, that may be acceptable. If a stock level is cached and a customer purchases the last item, the cache must be cleared or the system must handle the inconsistency gracefully. Deciding what to cache and for how long is a business decision as much as a technical one, because it involves weighing speed against accuracy for each type of data.

When discussing caching with a supplier, focus on which data is cached, how long it remains cached, and what mechanism exists to refresh or invalidate the cache when the underlying data changes. A system that caches aggressively but has no reliable invalidation strategy will eventually serve incorrect data to users.

What to check

• Which parts of the application use caching, and at what level?
• How long does cached data remain before it is refreshed?
• What happens when data changes: is the cache updated immediately, or does it expire on a schedule?
• Is there a way for an administrator to manually clear the cache if something looks wrong?

Database Performance and Indexing Explained

The database is often the limiting factor in application performance as data volumes grow. Understanding why requires a rough grasp of what indexing does, without needing to write SQL yourself.

Imagine a filing cabinet with ten thousand folders, sorted alphabetically by company name. Finding a specific company is fast because you can narrow down the drawer and section. But if you need to find all companies in a specific postcode, the alphabetical ordering does not help. You would have to check every folder. An index is, in effect, a second filing system organised by a different criterion, such as postcode. It takes up extra space and slows down writes slightly, because each new record must be added to both filing systems, but it makes certain queries much faster.

Most performance problems in business systems stem from queries running against large tables without appropriate indexes. A customer search that takes under a second with ten thousand records might take thirty seconds with a million records if the search field is not indexed. The solution is usually straightforward for a developer, but only if they know which fields your users actually search on and which queries run most frequently.

This is where business input is essential. A developer can index every column in a table, but unnecessary indexes consume storage and slow down data imports and updates. The right approach is to identify the queries that matter most to your operations and ensure those are optimised. That requires you to communicate which searches, filters and reports are used heavily and which are rare.

Other database considerations include whether large tables are partitioned, whether old data is archived rather than left in active tables, and whether the database server has sufficient memory to hold frequently accessed data in memory rather than reading from disk. These are technical decisions, but they should be informed by your knowledge of data growth rates and query patterns.

How to Handle Traffic Spikes in a Web Application

Traffic spikes are periods where usage temporarily exceeds normal levels. They can be predictable, such as end-of-month reporting in a finance system or a scheduled product launch, or unpredictable, such as a sudden surge in customer portal logins after an email campaign. The way your system is architected determines whether a spike causes a brief slowdown or a complete outage.

The first consideration is whether your infrastructure can scale automatically. Auto-scaling means the system detects increased demand and provisions additional server capacity without manual intervention. Not all architectures support this easily. A monolithic application running on a single server cannot scale horizontally by adding more servers unless it is designed to distribute work across them. A system built with stateless services, where any server can handle any request, scales more readily.

If auto-scaling is not feasible, the alternative is to provision for peak capacity in advance. This means paying for resources you do not use most of the time, which increases running costs but provides certainty. For internal systems with predictable peaks, this can be the more pragmatic choice.

Another strategy is to smooth demand using queues. If a spike involves users submitting large batches of data or requesting resource-intensive reports, those requests can be placed in a queue and processed sequentially rather than all at once. The user sees a message indicating that their request is being processed, and the system works through the queue at a sustainable rate. This does not make the individual request faster, but it prevents the system from becoming unresponsive for everyone.

For unpredictable spikes, monitoring is critical. If you do not know a spike is happening, you cannot respond to it. Alerting thresholds should be set so that your team or your supplier is notified before the system reaches its limit, giving time to take action such as scaling up, temporarily disabling non-essential features or diverting traffic.

Questions for your supplier

• Can the system scale automatically under load, and how quickly does that scaling happen?
• What is the maximum capacity before performance degrades, and how was that figure determined?
• Are there any processes, such as bulk imports or report generation, that can be queued rather than run synchronously?
• What alerting is in place to notify us of unusual traffic levels?

Performance Budgets for Web Applications

A performance budget is a set of constraints that prevent the application from becoming slower as new features are added. Without a budget, each release tends to add a little more code, a few more database queries and slightly larger page loads. Individually, each addition is minor. Cumulatively, they erode performance to the point where users notice.

In practice, a performance budget defines limits for the metrics that matter to your users. These might include the maximum page load time for key screens, the maximum number of database queries per page request, the maximum size of data transferred per page, or the maximum time allowed for a specific API call. The exact metrics depend on your application, but the principle is the same: once a limit is set, any change that would breach it requires a justification and, usually, an offsetting optimisation elsewhere.

Performance budgets are most effective when they are treated as acceptance criteria. If a new feature causes the dashboard to load in four seconds instead of the budgeted two seconds, the feature does not pass acceptance testing until the performance regression is addressed. This forces the development team to consider performance as part of the design, not as a cleanup task after launch.

Setting sensible budgets requires baseline measurement. You cannot set a meaningful limit without knowing where the application currently stands. Measure the key screens and operations before development begins, set budgets slightly tighter than the current performance to allow for some growth, and review the budgets periodically as the system evolves.

One common mistake is setting budgets that are too aggressive, which either forces the team to spend disproportionate time on micro-optimisations or leads to the budget being ignored because it is seen as unrealistic. Another is setting budgets only for initial page load and ignoring the performance of in-application actions such as saving records, switching tabs or running filters. For a business system, the latter are often more important than the former.

Implementing a performance budget

• Measure baseline performance for the five to ten most-used screens and actions before development starts.
• Set limits that are tighter than current performance but not so tight that they become impractical.
• Include performance checks in the acceptance criteria for every feature or change.
• Review and adjust budgets quarterly, or whenever significant new functionality is added.