Scaling begins with the workload the business needs to support and the constraint that currently prevents it.
Scaling begins with the workload the business needs to support and the constraint that currently prevents it. A full rewrite is rarely a useful first experiment because it changes many variables before proving which one matters. Establish a baseline for an important journey, then increase capacity through changes whose effects can be measured and reversed.
Describe traffic as work
Record request mix, concurrent users, payload sizes, background jobs and external dependencies. Distinguish a traffic spike from sustained growth. A browsing-heavy workload behaves differently from bulk imports or payment processing. Set an acceptable latency and failure level for the journey rather than declaring that the whole platform must support an unexplained user count.
Follow the waiting time
Use traces and database measurements to separate application execution from queueing, connection waits and provider delays. Inspect slow queries, repeated lookups and unbounded result sets before adding servers. Compare tail latency as well as averages. If workers contend for the same database locks, increasing their number can reduce throughput rather than improve it.
Apply the smallest relevant intervention
An index, bounded pagination, removal of repeated queries or movement of non-interactive work to a queue may address the measured constraint. Cache only data with a defined freshness and invalidation policy. When adding application instances, verify session handling, connection limits and deployment behaviour. Each intervention should have an expected effect and a measurement that could disprove the hypothesis.
Protect the improved path
Repeat the workload with representative data and observe the next bottleneck. Verify correctness, not just response times: retries, queue delays and caching must not change balances or permissions. Add limits and monitoring for the new capacity boundary. Record what improved, what remained unchanged and the trigger for the next investment. This creates a sequence of justified changes instead of a speculative platform replacement.
- Related service
- Cloud architecture review: reliability and cost together
- Code audit or penetration test: choose the evidence you need
Frequently asked questions
Should we add a cache first?
Only when repeated reads are the constraint and stale data has an acceptable, explicit meaning.
Is autoscaling enough?
It helps suitable compute workloads but does not remove database contention, provider limits or inefficient queries.
Why measure tail latency?
Averages can hide a group of users waiting much longer, particularly during contention or dependency failures.
Can tests use tiny synthetic datasets?
They help isolate behaviour but may miss query and storage effects. Include representative volume and distribution safely.
When might a rewrite be justified?
When bounded changes cannot address demonstrated constraints and the migration risk is understood, not merely because growth is expected.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
Cloud architecture review: reliability and cost together
A cloud architecture review connects expenditure to useful work and reliability to tested recovery.
Code audit or penetration test: choose the evidence you need
A code audit and a penetration test answer overlapping but different questions.
Software architecture review: the evidence checklist
An architecture review should explain whether the current system can support the next business decisions.