A service is scalable when adding resources increases its capacity in proportion to the resources added. Capacity can mean more units of work, or larger units of work as data grows. A word on scalability gives the original framing.
Performance and scalability describe different failures:
- A performance problem makes the system slow for one user or one request.
- A scalability problem leaves one request fast but makes requests slow under heavy load.
- Increasing load
More concurrent users or request rate consumes capacity.
- Unchanged bottleneck
A non-scalable path reaches a bottleneck and latency rises.
- Useful scaling
Resources added at the limiting component can increase sustainable capacity.
- New saturation
Every design still has limits. This instrument shows a qualitative relationship, not a measured curve.
Scaling delays saturation only when the added resources address the actual limiting work.
How to read this model
A capacity gauge beside an expandable worker holder. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Scalability does not mean that latency never rises. Every design has a saturation point. The useful question is how much load the system handles before a bottleneck makes latency unacceptable, and how predictably more capacity moves that point.
Common levers include reducing work per request, caching repeated reads, adding replicas, partitioning data, and moving slow work to a queue. Each lever changes consistency, cost, or operational complexity. Measure the current bottleneck before adding one.
For the relationship between response time and completed work, read latency and throughput. Load balancing and database scaling show two common ways to add capacity.