What is Scalability?

Before depending on any system, ask it one question: what happens when ten times more arrives — traffic, orders, users, data? A scalable system absorbs the growth by adding resources, ideally automatically and in proportion to cost; a non-scalable one collapses precisely at the moment of success — the winning campaign that kills the website, the Black Friday that freezes orders, the internal app that "worked perfectly" for 10 people and crawls at 100. Technically there are two roads: vertical scaling (a more powerful server — simple, but with a ceiling and a single point of failure) and horizontal scaling (more instances sharing the load — the modern cloud model, theoretically unlimited, but demanding an application built for it: not every codebase can run as ten parallel copies without trampling its own data). Hence the procurement lesson: scalability is designed in, not bolted on — an application built without that thought gets expensively rewritten when growth arrives; so the right questions to a vendor are concrete: what volume is this sized for? what happens at a 10x spike — automatic, or does someone intervene? which component gives out first, and how do we find out before it does? The nuances that keep the discussion honest: scalability costs money (architecture for millions, paid for by a firm with hundreds of users, is waste — overprovisioning is the mirror error of undersizing; you size for reality plus one order of magnitude, with a clear path beyond), the bottleneck usually hides elsewhere than expected (the database, not the web servers, is the classic weak heel — and "more hardware" fixes neither a bad query nor missing caching) and, beyond technology, there is operational scalability — the company's processes: a system that technically carries 10x helps little if every order still needs a human touch; real growth scales both.