Nowadays it is difficult to find a piece of software which is not scalable by some measure. That is perhaps not only due to the fact that it was originally designed to be scalable in the first place, but rather in a larger context systems operate nowadays. As an example lets take a popular webserver, say Apache. It was of course designed with some scalability in mind, in terms of adding more worker processes when number of requests increases, and can do it in very intelligent and effective way. However, at some point the system resources would be exhausted and that can put the limits to the maximum number the server can handle. But if you look it at larger context - a webserver does not have to be a single standalone machine anymore: it can be a set of identical webservers, server by a load balancer, which distributes load between individual servers. In such way the capacity can increase far beyond limits of what single server can do. And this functionality was not necessary designed and buit in by Apache designers in the first place.
The definition of scalabilty says that there are two dimensions of scalability: horizontal, where adding more similar nodes increases system performance. That is the case described above in the example of webserver. The other dimension is vertical, where adding more resources (usually hardware) to the same node will add more capacity. But maybe in a wider system context there is another dimension, which is neither vertical nor horizontal: splitting different tasks to different nodes. if we take an example of webserver, that would be taking apart work of processing an individual request, and delegating these tasks to different nodes. That, of course, is not new concept: the proxy in front of webserver can do TLS negotiation and decoding, pass unencrypted traffic to webserver, therefore reducing the load. In the larger setups database are split on the separate servers, further reducing loads etc.
The scalability of this third mode (neither vertical nor horizontal) is a task of system architects. That mostly boils down to designing the system in a way that it can be separated in small, "atomic" tasks which can eventually run on their own, on a separate server, a.k.a. microservices. They are easier to manage, profile their performance, and debug. They can be initially set to operate to share single resource , i. e. single server and later, based on each process performance decided either to move to the separate hardware or not. And besides that, two of the other scalability dimensions apply as well.
To sum up, in the context of the system, not a single application, there are more than 2 dimensions of scalability. The system architects as well as developers should be aware of it.
