Scaling is changing a system’s capacity so it can handle more users, requests, data, or work while keeping an acceptable experience.
Scaling means increasing or decreasing the resources available to a system as demand changes.
Capacity can mean requests per second, concurrent users, storage, queue throughput, or the time needed to finish a job. Scaling is a product and architecture decision, not only a server-size decision.
Think of scaling like opening more checkout lanes or making one lane faster.
More lanes spread work across workers. A faster lane helps one worker do more. Each option changes cost, coordination, and the failure surface.
Handle launches, campaigns, and other demand spikes.
Give busy components enough CPU, memory, connections, or workers.
Match capacity to demand instead of paying for a permanent peak.
Keep latency and error rates inside agreed service targets.
Scale web traffic, background jobs, databases, caches, file services, message consumers, and storage capacity. The bottleneck may be a dependency rather than the component receiving the traffic.
During a sale, the product team expects five times the normal checkout traffic. Engineers add application instances, increase queue consumers, check database connection limits, and watch latency and error rate during the event.
More instances do not help if the database, payment provider, or file service is the limiting component.
Change capacity to meet demand.
How efficiently and quickly a system works.
Keep the service usable when parts fail.
Improve resource use or behavior, which may reduce the need to scale.
See the Module 07 Glossary for the shared bilingual vocabulary.
Scaling is about capacity against demand. A PM should name the demand signal, the user-facing target, the bottleneck, and the cost or reliability guardrail.