Scalability

The number in someone's head while they're first building is usually a small one. Code written for a hundred simultaneous users stays exactly as it was written, and then collapses on the day the real user count arrives.

That day showed up abruptly at Pagedeck one week. A share link a customer created spread through an industry community and concurrent users jumped from the low hundreds to the low thousands, peaking around eight thousand. What stopped first wasn't the servers, it was the document list screen, because drawing that list read every document in the account each time it was shown. With twenty documents in an account there was no problem at all; with eight thousand people arriving holding hundreds each, the database went down under it.

What the team learned was that adding servers wouldn't help. Bring up ten of them and the same heavy query simply arrives ten times over. Some structures get solved by adding capacity and some of them don't, and scalability is the word for that difference. Under software architecture — the large decisions about what pieces a system is cut into and how they connect — it's one of three quality attributes used to judge how well the cutting went.

There are two directions available. Vertical scaling raises the capacity of one machine, and the other adds machines. The first takes less work but ends at the best machine money can buy; the second can keep going indefinitely, provided the code was built to allow it.

Three things have to be in place before adding machines does any good.

1. The server can't be holding state between requests. That property is called stateless. Keep login information in server one's memory and the next request, landing on server two, makes that person look logged out. State goes into shared storage outside the servers, and each server reads it fresh on every request.
2. Something in front has to distribute the requests. A load balancer fills that role. Without one you can run twenty servers and all of the traffic still arrives at a single machine.
3. The data layer has to grow with it. Servers get added easily while the database is often left as one machine, and that machine becomes both the single point of failure and the ceiling for everything. The options are read-only replicas, sharding to split the data across several servers, or caching so the same result doesn't get computed twice.

With those three in place, even adjusting the machine count can be handed off, which is what autoscaling does automatically as load rises and falls.

Finding the ceiling follows one method: raise the load in steps and watch to see what fails first. If a hundred concurrent users get 200 milliseconds, a thousand get 400, and two thousand jumps to three seconds, then the ceiling sits somewhere near two thousand. Whatever gives way is always a single place, and fixing that one exposes the next one behind it. After the list query was fixed, Pagedeck's next ceiling turned out to be file upload.

It appears at three decision points: when a structure is being chosen, when a sudden rise in users is coming, and when somebody is calculating the server bill.

The bill is the one that comes up most often in practice. Saying a system is scalable also means the problem is one that can be solved with money. Doubling the servers to absorb double the load also doubles the cost of running them. So scalability doesn't get recorded as a yes or a no, but as how much it costs to hold up to what point. A structure that holds two thousand concurrent users for $770 a month and would demand $15,000 at twenty thousand needs revisiting well before that range arrives.

There's a trap on the other side: preparing for a scale that never comes. A 45-person company that assumes a hundred million users and cuts everything into microservices pays the daily cost of deploying and monitoring five services while the day that structure is needed never arrives. Pagedeck kept a single deployable piece and removed the heavy queries instead, and eight thousand concurrent users were absorbed inside that choice.

Three numbers written on one line carry the whole judgment: what the system holds now, the point where it breaks, and what it costs to hold the space between those two. Next quarter's work gets read straight off that line.

"This isn't a problem you fix with more servers. One query reads every document in the account."

Pointing out a structure where adding capacity does nothing at all.

"The current structure holds to two thousand concurrent. Above that I can't promise anything."

Stating scalability as a number rather than as a yes or a no.

"Sessions in server memory mean we can't add servers. Let's move them out."

Naming the condition that adding more machines depends on.

At Pagedeck this conversation runs between Theo and Grace. Theo brings the current ceiling and the cost of holding above it as numbers, and Grace is the one who decides when that cost gets paid. Scalability looks like a technical decision and is really a decision about when to spend how much, so without both of them reading the same table, one side prepares for something unnecessary while the other gets a sudden invoice.

The most common reading treats scalability as a synonym for fast, since both get bundled under the word performance. The axes are different, though. A product that takes three seconds for one person and still takes three seconds with ten thousand of them is slow and scalable at the same time. A product answering one person in 100 milliseconds that climbs to twenty seconds at a thousand is fast and not scalable. Mix the two axes together and you end up fixing the wrong thing: a slow response means examining that one request, while a structure that collapses means looking at what else grows when users grow.

The other frequent belief is that designing big from the start solves it, a judgment that comes from having paid to fix something late. But where the load will land can't be known in advance. Pagedeck had prepared for simultaneous editing, and what broke was the document list. Preparation done early usually guards the wrong place, and the complexity it added stays behind regardless. The working order is the reverse: attach measurement first, so you can tell what fails first as usage grows, then fix the one place that failed.