# Scalability **In short:** Scalability is how well a system copes with growing workload by adding resources. A capacity limit always exists, and the bottleneck, often a stateful part like a database, decides how far scaling can go. ## Explanation Scalability describes how a system handles more work when you give it more resources. Always name the dimension you mean, such as user traffic, concurrent requests, or data volume. **Measuring it.** You can quantify scalability as the throughput gained per resource added. Throughput is the amount of work finished in a given time. The ideal is linear: double the resources, double the throughput. Real systems usually fall short. Bottlenecks and synchronization points limit the gain. Amdahl's law can model scale-out. It separates contention (waiting for shared resources) from coherency (the delay before data becomes consistent). **Two ways to scale.** - Horizontal scaling (scale out and in) adds or removes instances. It suits work that splits into independent parts. - Vertical scaling (scale up and down) changes the capacity of one resource. It often needs downtime. It suits work that is hard to divide, or architectures that cannot scale horizontally. In the cloud, elastic scaling means you scale out as load grows and scale in when it falls. Supply then follows demand. **Stateless versus stateful.** Stateless components spread easily across instances, because any instance can handle any request. Session affinity (stickiness) undermines this. It ties a user to one instance, so a high-volume user's traffic is not spread out. Stateful components and dependencies make horizontal scaling harder. Databases need careful design, such as data partitioning. **Find the bottleneck first.** Adding web servers does not help if the database is the bottleneck. Stateful parts are the likeliest bottlenecks, so identify them before you scale out. **Limits.** Every resource has an upper scale limit. Beyond it, you must partition the workload. A capacity limit always exists. ISO/IEC 25010 files Capacity under Performance Efficiency: whether the maximum limits of a system parameter meet requirements. Autoscaling needs a maximum instance count and throttling. A configured maximum does not prove that dependencies can carry the load. When demand exceeds safe capacity, throttle incoming work or reduce nonessential functions. **Patterns.** Load balancing without client affinity spreads requests. Queue-based load leveling and competing consumers use a message queue to absorb extra work. Consumers then drain it at their own pace. **Testing.** A scalability test defines workload dimensions and measures response time, throughput, and error rates at increasing load. ## Example An online shop expects more visitors during a sale. The team states the dimension: concurrent shoppers. Web servers keep no session data, so a load balancer can add instances freely. Tests show the order database slows first. The team partitions its data before adding more web servers. A queue absorbs spikes of order confirmations. A maximum instance count and throttling protect the database. ## Trade-offs Vertical scaling is simple but often needs downtime and has a hard upper limit. Horizontal scaling needs work that divides into independent parts, and stateful parts need extra design such as partitioning. Autoscaling can push load onto dependencies that cannot carry it, so it needs limits and throttling. ## Checks - The scalability requirement names its workload dimension, such as concurrent requests or data volume. - Bottlenecks, especially stateful parts like the database, are identified before scale-out is chosen. - Autoscaling has a maximum instance count and throttling, and dependencies are checked against it. - Load balancing does not rely on session affinity. - Scalability tests measure response time, throughput, and error rates at increasing load. ## Related - [Performance Efficiency](https://arc.fuet.ch/concepts/quality-attributes/performance-efficiency.md) - [Load Balancer](https://arc.fuet.ch/concepts/tactics/load-balancer.md) - [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md) - [Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-scenario.md) - [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md) - [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md) - [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md) - [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md) ## Sources - [Architecture strategies for optimizing scaling and partitioning - Microsoft Azure Well-Architected Framework | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/scale-partition) — learn.microsoft.com, accessed 2026-11-09 - [Design to scale out - Azure Architecture Center | Microsoft Learn](https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/scale-out) — learn.microsoft.com, accessed 2026-11-09 - [Autoscaling Guidance - Azure Architecture Center | Microsoft Learn](https://learn.microsoft.com/en-us/azure/architecture/best-practices/auto-scaling) — learn.microsoft.com, accessed 2026-11-09 - [ISO 25010](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010) — iso25000.com, accessed 2026-11-08