Will a system need to be rebuilt if business volume grows tenfold?
A tenfold increase does not automatically require a rebuild, and no responsible team can promise that the current design will absorb it without evidence. Wavesteam converts the growth plan into peak load, data and file growth, background work, third-party limits, and availability objectives, then tests with production-like data. Scale and optimize first; restructure only where a measured resource, data boundary, or failure domain becomes a hard limit.
“Ten thousand users today and one hundred thousand later” is not a capacity model. Registered users are not concurrent users, and a product view costs less than a payment or inventory update. The client supplies business history, planned campaigns, and the consequences of interruption. Wavesteam derives daily activity, peak concurrency, critical request mix, read/write ratio, data growth, scheduled jobs, external quotas, and the duration of promotion or month-end peaks.
When decomposing features, data, and acceptance scenarios, also compare Will unclear requirements cause a custom project to be rebuilt halfway through?; the linked guidance adds context that should be considered in the same decision.
| Evidence | First response | Structural change becomes plausible when |
|---|---|---|
| Application CPU or connections saturate | Add stateless instances; inspect pools and hotspots | Session or local state prevents horizontal scaling |
| Queries and database I/O dominate | Improve plans, indexes, batching, and archiving | Primary writes, locks, or table size reach an economic hard limit |
| External services block the main path | Add timeouts, rate limits, queues, and degradation | The dependency needs independent scaling or failure isolation |
| Reporting harms transactions | Use replicas, offline computation, or an analytical store | Analytical and transaction models remain fundamentally incompatible |
| Large files exhaust application resources | Move to object storage, multipart upload, and CDN | Region or regulatory boundaries require separation |
Establish a capacity curve on the current version. Fix the hardware, data snapshot, and workload, increase load progressively, and record throughput, P50/P95/P99 latency, errors, CPU, memory, database connections, storage I/O, queue backlog, and supplier failures. The point at which an agreed service objective first fails shows the usable margin. Google's SRE service best practices likewise connect load testing to capacity rather than relying on an abstract growth multiplier.
Use representative traffic. A login-only test says nothing about checkout, inventory, or reporting, while an empty database hides index degradation. Run writes in an isolated environment with sanitized or synthetic data and include hotspot accounts, retries, timeouts, duplicate requests, and third-party degradation. A longer stability test exposes leaks, unreleased connections, and queues that never recover.
The first release should include inexpensive paths to evolve: mostly stateless application processes, externalized configuration and secrets, object storage for files, idempotent queued work, traceable migrations, stable keys, and observability. Clear code-module boundaries do not all need separate deployment. Cache, replicas, and queues add consistency and operational cost and should be introduced for an evidenced need—not as decorative architecture.
Refactoring becomes justified when vertical scaling is no longer economical, write or lock constraints persist, one failure repeatedly takes down unrelated business, release and resource patterns require isolation, or regulation creates a separate data boundary. Split the measured bottleneck and design migration, validation, rollback, and data consistency first. Avoid a simultaneous “new platform” rewrite.
Acceptance should name the snapshot, instance configuration, transaction mix, duration, latency and error thresholds, recovery of the queue after peak, and behaviour during an instance failure. These figures come from forecast, budget, and business risk. Wavesteam delivers the model, assumptions, scripts, resources, results, known limit, and staged recommendation; the client decides investment based on business value. The Transparent Delivery Standard describes the evidence and handover boundary.