The attributes behind your decision
- Decision input
- Measured workload
- Primary variables
- Capacity, control, operations
- Validation
- Representative testing
- Next step
- Swiss infrastructure
Define traffic as workload
Requests per second, page generation cost, cache hit rate, payload size and logged-in behavior matter more than a monthly visitor total. Identify the busiest paths.
Remove application bottlenecks before adding capacity
Profile slow queries, external calls, background queues and expensive rendering. Caching and efficient code can increase capacity without changing the server.
Load-test a realistic environment
Use representative data and request mixes, increase load gradually and observe latency, errors, saturation and recovery. Do not treat a synthetic peak as a traffic guarantee.
Create thresholds for the next architecture step
Decide when to add resources, separate the database, introduce replicas or move to dedicated hardware. Keep deployments and rollback workable as complexity grows.
Find the bottleneck before adding capacity
High request volume can stress the web process, cache, database, storage or an external service. Capture response-time percentiles and errors during representative traffic, then compare those measurements with server metrics. Low average CPU does not prove that database queries or external calls are healthy.
Use caching where the content permits it and test the uncached paths separately. Plan traffic peaks, queue behavior and rollback for releases. Scale the component that measurements identify, then repeat the same workload test so the effect of the change can be assessed consistently.