A company is preparing for a major customer launch expected to roughly triple traffic.
The application performs well today, so the first proposal sounds straightforward: increase cloud capacity before launch and let autoscaling handle the rest.
Then the team runs a realistic load test.
At around 1.8 times normal traffic, API instances begin scaling as expected. CPU drops as new instances come online, but response times keep rising. The database connection pool is already exhausted, a third-party API starts throttling requests, and background jobs accumulate faster than workers can process them.
The application could scale its web servers.
The application as a whole was not ready to scale.
That distinction matters.
Scaling readiness is not simply having an autoscaling configuration or knowing that additional servers can be provisioned. An application is ready to scale when growing demand can be absorbed without an unexpected bottleneck elsewhere causing unacceptable latency, errors or operational instability.
Microsoft's current Well-Architected guidance recommends capacity planning around real workload constraints, including resource limits and external dependencies, and specifically advises testing different usage patterns rather than assuming additional resources will translate directly into additional capacity.
For Levelworks, this is primarily the Scalable dimension of App Health. Performant and Observable reinforce it: scaling is much safer when the application meets performance expectations at increasing load and teams can see which component is approaching its limit before customers discover it.
"Can this application handle more traffic?" is too vague to test.
More traffic could mean:
Those are different scaling problems.
An application may support twice as many users while failing when individual accounts contain ten times as much data.
A SaaS product might handle normal growth comfortably but struggle when thousands of customers log in simultaneously after an announcement.
Before testing readiness, write down the expected growth scenario.
For example:
Within 12 months, peak API traffic may increase from 800 to 2,000 requests per second, concurrent sessions from 6,000 to 15,000, and the largest customer dataset from 3 million to 8 million records.
Now engineering knows what "ready" means.
Without that definition, a successful load test merely proves that the system survived whichever workload happened to be generated.
An application already running close to its limits has very little scaling margin.
Establish how heavily critical resources are used during normal and peak operation.
Depending on the architecture, inspect:
The goal is not to keep every resource artificially underused. It is to understand how much additional demand can arrive before something changes materially.
Imagine the application normally operates at:
Adding more application instances may create plenty of compute capacity, but it could also create more database connections and push the database beyond its practical limit sooner.
This is why capacity has to be viewed across the request path rather than one infrastructure layer.
Microsoft's capacity-planning guidance specifically recommends identifying scaling limits and using workload testing to understand how architecture behaves as demand changes.
Every system eventually encounters a limiting resource.
The useful question is:
Which resource becomes the constraint first?
Gradually increase load and watch what changes.
Suppose throughput rises normally until 1,500 requests per second.
Beyond that point:
The application's current scaling boundary is probably not compute capacity. It is database access.
A useful scaling test records behaviour across increasing load:
Load
p95 latency
Error rate
DB connections
Queue depth
500 req/s
420 ms
0.1%
80
5
1,000 req/s
510 ms
0.1%
135
12
1,500 req/s
760 ms
0.2%
185
35
1,800 req/s
2.1 s
1.4%
200/200
410
2,000 req/s
4.6 s
6.8%
200/200
1,900
That tells a much richer story than:
The application handled 2,000 requests per second.
Technically, it did.
Whether it handled them acceptably is another matter.
Do not stop the test when you reach the traffic level you expect.
Go beyond it.
AWS's current Well-Architected guidance recommends load testing beyond expected production load so teams can discover bottlenecks before real traffic reaches them. It also recommends testing the overall workload rather than isolated components and validating resource settings, scaling configuration, service quotas and resilience under load.
If you expect peak demand of 2,000 requests per second, testing exactly 2,000 tells you little about your safety margin.
Testing progressively beyond that may reveal:
You do not need every workload to tolerate infinite growth.
You do need to know how close expected demand sits to the application's practical boundary.
[Internal Link: “Load Testing vs Stress Testing: What Does Your App Need?”]
Adding application instances works most naturally when any healthy instance can handle the next request.
Problems appear when individual servers hold state that users depend on.
Suppose login creates session data in the memory of Server A.
The load balancer sends the user's next request to Server B.
Server B knows nothing about the session.
Teams sometimes solve this with sticky sessions, permanently routing a user to the same instance. That can work, but it reduces some of the flexibility horizontal scaling is supposed to provide.
AWS recommends making application services stateless where practical because requests can then be handled by any available compute instance, which makes capacity easier to add or remove. Microsoft makes a similar recommendation for horizontally scalable workloads, warning against assumptions that subsequent requests will always reach the same application instance.
Before declaring the application horizontally scalable, ask:
The answer does not always need to be "completely stateless."
It does need to be intentional.
Application servers are often relatively easy to multiply.
The database is frequently harder.
Suppose application traffic doubles and autoscaling creates twice as many service instances. Each instance opens a pool of 50 database connections.
The application tier now has twice the capacity to generate database traffic—but the database has not automatically gained twice the ability to process it.
Microsoft's scalability guidance explicitly identifies stateful workload components such as databases as common dependency bottlenecks when scaling other parts of a system.
Before major growth, understand:
This is especially important when growth involves data size, not only user count.
An application may handle 50,000 small customer accounts very differently from 5,000 accounts containing enormous histories.
Scaling readiness therefore needs representative production-sized data, not merely more simulated users.
Interactive traffic is only part of many applications.
User activity may create work such as:
The user-facing request may remain quick because the work is queued.
That does not mean the application is scaling successfully.
Suppose traffic triples and queue production rises to 30,000 jobs per minute while workers can process only 15,000.
The front end initially looks healthy.
One hour later, jobs are significantly delayed. Several hours later, the backlog is enormous.
Scaling readiness should therefore examine:
arrival rate versus processing rate.
Measure:
If queues grow continuously at expected future demand, background capacity is already below the required level.
Your own infrastructure may be ready while an external service is not.
Applications commonly depend on:
Those providers may enforce:
Cloud infrastructure itself also has quotas and fixed constraints.
AWS specifically warns that service limits such as network capacity, API throttles and concurrent database connections can become architectural constraints under high load. Its guidance recommends monitoring usage relative to quotas rather than discovering those boundaries during a traffic event.
Create an inventory of the limits that sit on critical workflows.
For each one, know:
An application is not ready for 10x growth if a business-critical provider begins throttling at 3x.
Autoscaling existing infrastructure does not automatically make an application scalable.
The trigger matters.
CPU is commonly used, but CPU may not be the resource determining application capacity.
A service could be saturated because:
CPU may still look normal.
Kubernetes' Horizontal Pod Autoscaler, for example, can scale workloads using CPU, memory and custom or external metrics rather than being limited to one built-in resource signal.
Choose a scaling signal that moves meaningfully with the workload you are trying to accommodate.
For a queue worker, backlog may be more useful than CPU.
For an API, requests per instance or concurrency might provide stronger evidence than memory.
Then test whether scaling begins early enough to matter.
Scaling is not instantaneous.
New capacity may require time to:
If demand rises faster than capacity arrives, the application can still fail even though autoscaling eventually reaches the correct number of instances.
Microsoft explicitly recommends testing scaling delays when evaluating scalability, because the system's reaction time affects whether it can absorb real-world demand changes.
This matters especially for sudden events.
An application that can comfortably scale from 10 instances to 50 over fifteen minutes may be ready for gradual growth but poorly prepared for traffic that increases fivefold in thirty seconds.
Scaling readiness therefore depends not only on how far capacity can grow but how quickly it gets there.
Scaling successfully is not the same as remaining online.
Suppose the application handles five times normal traffic without errors, but checkout latency increases from 700 milliseconds to nine seconds.
From an infrastructure perspective, the application survived.
From a user perspective, it did not scale well.
Track performance and errors alongside throughput:
The purpose is to confirm that adding demand does not make the application's important workflows progressively unusable.
This is where Scalable and Performant App Health overlap. A scalable application should not merely accept more work; it should continue providing acceptable service while doing so.
Scaling without observability creates a dangerous situation: the system grows, but nobody knows which limit it is approaching.
Before a major growth event, teams should be able to answer questions such as:
Without those signals, capacity management becomes reactive.
This is why Observable App Health supports Scalable. The objective is not collecting dozens of infrastructure graphs; it is detecting when a component is approaching the point where further demand changes application behavior.
Eventually, something reaches a limit.
Scaling readiness includes knowing how the application behaves then.
Does it:
This does not mean every application requires sophisticated degradation mechanisms before it can grow.
It means teams should know what happens at the boundary.
An unknown breaking point is much riskier than a known capacity limit with controlled behaviour.
[Internal Link: “How to Scale an Application Without Sacrificing Performance or Reliability”]
A practical scaling review can be summarized as follows:
Readiness question
Evidence you want
Do we know expected future demand?
Traffic, concurrency and data-growth forecast
Do we know current capacity?
Baseline utilization and throughput
Do we know the first bottleneck?
Load-test evidence
Have we tested beyond expected demand?
Performance curve and breaking point
Can compute capacity be added safely?
Proven scaling test
Does local state prevent new instances helping?
State/session review
Can the database support additional load?
Database capacity and query evidence
Can background workers keep up?
Queue/worker throughput data
Are third-party limits understood?
Quota and dependency inventory
Does autoscaling use meaningful signals?
Scaling-policy validation
Does capacity arrive quickly enough?
Scale-up timing test
Does latency remain acceptable?
p95/p99 and business workflow measurements
Can we see approaching saturation?
Monitoring and alerts
You do not need perfect results in every category before growing.
You do need to know where uncertainty remains.
Scaling readiness is not only about the next launch.
Demand continues changing after that.
Once the application's current limits are understood, compare them with expected growth so engineering can identify when another capacity decision will be required.
If the database becomes constrained around 4,000 transactions per second and traffic grows approximately 15% each quarter, the team has a useful planning signal.
If nobody knows the database boundary, capacity planning turns into waiting until production starts slowing down.
[Internal Link: “Application Capacity Planning: Preparing Your App for Growth”]
This is also why scaling assessments should be repeated after meaningful changes. New functionality, different traffic patterns, more data and additional dependencies can all move the bottleneck.
Microsoft recommends refreshing performance and capacity baselines after significant workload changes so scaling assumptions remain relevant rather than becoming historical documentation.
An application is not ready to scale simply because it runs in the cloud, has an autoscaler or survived yesterday's traffic.
It is ready when the team can describe, with evidence:
AWS summarizes the testing side of this well: scalability should be validated under realistic production-like load, including the application's base resources, scaling configuration, quotas and resilience mechanisms—not inferred from architecture diagrams.
For Levelworks, this is the substance of Scalable App Health. Scalability is not theoretical permission to add more infrastructure. It is the application's demonstrated ability to accommodate increasing demand without its performance, reliability or operability deteriorating unexpectedly.
The question is therefore not simply:
“Can we add more capacity?”
It is:
“When demand grows, do we know which parts of the application will absorb it, which part will reach its limit next, and whether users will still receive an acceptable experience when we get there?”
If those answers are based on measurements rather than assumptions, the application is much closer to being genuinely ready to scale.
