Scalability is not a property of the system, but rather its behavior under increasing load. We analyze how architecture changes with increased throughput and latency requirements.
The first failure in scaling usually does not appear as a failure. The system “operates as before,” but under load, latency increases, throughput deteriorates, and unstable spikes occur. The reason is almost always the same — an increase in load. This can be an increase in concurrent users or data volume. The key issue is that scalability cannot be assessed abstractly. The statement “the system scales” is meaningless without the context of the load: read/write ratio, peak values, request distribution. Without these parameters, any architectural decisions are mere guesses. A common mistake is premature optimization. At an early stage, a complex architecture reduces flexibility and slows down product development.
The solution begins not with the choice of technology, but with formalizing the load. Engineering-wise, this means: measuring throughput (requests per second, ingestion rate), determining peak values, and understanding the data access profile. Only after this can one model growth: what will happen under x2 load. Here, a trade-off arises between cost and performance. Linear scalability is considered a good benchmark: doubling resources yields double the load at the same latency. In practice, this is rarely achieved. More often, costs rise faster than performance. The reasons are the increase in data volume and the growing complexity of operations. Even the same write request becomes “more expensive” with a large dataset.
Next is the choice of architecture. Vertical scaling (scaling up) is the simplest path: more CPU, RAM, disk. It provides quick results but does not scale well in terms of cost. High-end machines are disproportionately expensive and do not provide linear gains. Parallelism through threads runs into shared-memory limitations. Shared-disk architecture solves some problems but adds contention and locking overhead. This limits scalability as the load increases.
Therefore, the industry has shifted towards horizontal scaling (shared-nothing architecture). Here, each node is independent: its own CPU, RAM, and storage. Coordination occurs at the network and software level. This provides several effects:
- potential linear scalability
- flexibility in infrastructure choice (especially in the cloud)
- increased fault tolerance through distribution
But the price is complexity. Sharding, distributed transactions, and network latencies arise. Any error within the data boundaries leads to load imbalances. In this sense, microservices and sharding are not “optimizations,” but a way to manage complexity through decomposition.
An interesting compromise is the separation of storage and compute. In such systems, compute nodes operate separately, and data access occurs through a specialized storage API. This is similar to shared-disk but without the classic bottlenecks of NAS/SAN. This approach reduces coupling and allows layers to scale independently. However, it requires precise API tuning and an understanding of the workload.
Implementing a scalable system is almost always iterative. An architecture that works under one load breaks down under an order of magnitude increase. This is normal behavior. Practice shows that planning beyond one order of growth is rarely justified. There are too many unknowns: the product changes, usage patterns change. Therefore, systems evolve alongside the load.
The key engineering principle is decomposition. Dividing the system into independent components reduces the impact of local bottlenecks. But the boundaries of these components are the most challenging part of the design. A mistake here leads either to excessive coupling or costly coordination. The second principle is to avoid complicating things. If a single-node database meets current latency and throughput requirements, a distributed system will only add operational risks.
The result of this approach is not an “ideally scalable system,” but a managed evolution. Metrics improve only where it is truly necessary. Often, without precise numbers, it is impossible to assert how much better the system has become — and that is acceptable. What matters is that the architecture begins to align with the actual load, rather than a hypothetical future.
There is no universal recipe for scalability in the industry. Systems with the same throughput can have radically different architectures due to differences in request sizes or load profiles. Therefore, the main conclusion is pragmatic: scalability is a series of trade-offs, not a final state.