Scalability is a software system’s ability to hold its behaviour and its results steady while records, requests and users multiply, with no rebuild required to get there. The definition leaves out which number grows, and a proposal that calls a system scalable cannot be checked until that number has a name. Vipkurum counts institutions, and the growth it has to take presses on the boundary between them rather than on any user count.
What scalability means in software
Ask whether a system scales and the honest answer is another question. No system is open to every kind of growth: each one takes the growth its design expected and strains under the growth it did not, which makes scalability a matter of degree rather than a yes or a no. What a vendor can be held to, then, is not that something scales but the growth it scales under.
Growth survived by rewriting is still growth survived, and it is not evidence of anything. That is the half of the definition people skip: taking an increase must not mean building the thing again. The other half is behaviour, which is the same job getting done the same way while the counts climb.
Which of the two scaling methods any search will offer you is not what this article settles, since that choice only becomes answerable once the growing count is named. Both of them describe how an increase gets absorbed, and neither of them says which count is increasing. Vertical means the machine doing the work gets stronger; horizontal means more machines share it.
One more meaning gets in the way. Business writing calls a model scalable when revenue can climb without cost and headcount climbing with it, which is a different subject from this one. In the software sense the definition goes quiet exactly where it matters, on which number is about to move, and a reader left in that silence fills it with whatever growth they have in mind.
Scalability is not speed
The screens in a demonstration open on a handful of records, every click lands at once, and the speed in the room gets read as a promise about growth. Today’s load was the only thing on display, and how the same screen behaves once the records pile up was not. No single scene muddles the two words more reliably.
A screen that opens instantly on today’s load can choke once the load climbs, and a report that is slow this morning can hold that same pace afterwards. Quickness and growth come apart in both directions, which is why a stopwatch reading proves nothing either way, however reassuring it looks in a proposal.
One is a measurement taken this morning; the other is a prediction nobody can time. Performance is the measurement: a duration under the load a system carries now, whether that is a page opening, a request answered or a report coming out. Scalability is the prediction, and what it asks about is that same duration, and the behaviour around it, once the load is larger. Neither reading substitutes for the other, and a proposal that offers one while being asked about the other has answered a different question.
The reverse case is worth having in mind, because a scalable system has no duty to be fast: one that keeps its behaviour as the load climbs can be measured in the same unhurried way today and next year. What changes with the question is the kind of evidence that counts. A timing tells you about this morning, and for the growth question the thing to look at is how the record behind the screen is kept.
The missing half of “will it scale as we grow”: what grows
Four shapes of growth turn up across our own work, and naming them is the only way to fill the gap the definition leaves. In exam scoring the number that climbs is the count of places where answer sheets get read. In a perfume shop one scent is sold in several sizes, and those sizes are what get counted. On an education platform it is institutions, each arriving with a boundary of its own, while on a weather site it is the date and location breakdown.
Say nothing about which growth you expect and the answer you get may describe something your business never sees. The pressure points differ one from the next: organisations press on the boundary between data sets, working points press on the step everyone waits for, records press on the structure of the pages, and a catalogue presses on the record model. Those four points are where “the number goes up” stops meaning one thing.
Will it scale as we grow is the question buyers bring, and the answer tends to come back in the shape it arrived in, with both sides leaving the table thinking they agreed about something. What the question leaves out is what is expected to grow. When a layer should be added is a different question again, and it is taken up on the web development page that answers “can it scale as we grow”.
Leave the growth unnamed and the structure still gets built, only against whatever growth was assumed, with the assumption written down nowhere. Naming it is the buyer’s job, since the side running the operation knows which number moved and a developer can only guess. The list to check is the one the business has already lived through: institutions, working points, records or products, and whichever is about to climb comes off that same list and can be carried into a planning call in writing.
When organisations multiply, what grows is the boundary
How many distinct boundaries can hold their shape under one roof? That is the growth question here, because organisations arrive one boundary at a time: each brings its own data, its own name and its own look, and none of that should touch the records next door. Users multiply inside each of them, and that is not the number under pressure.
When another institution joins Vipkurum, nobody installs a new system; the platform stays single and the institution is defined inside it under its own name. How a platform of that kind gets put together is laid out in building a multi-tenant system.
The tempting alternative is a copy for each organisation, which turns growth into a count of installations. Whatever draws the boundary has to keep drawing it the same way for every organisation that arrives afterwards, since a boundary that holds only for the first one is not a boundary.
Boundaries built up front are a cost carried today against an arrival that is not coming. A business that will only ever run one organisation never meets this growth, and the boundary question never arises for it.
When branches multiply, the breaking point is a single point
More branches put their strain on one step everyone has to pass through, which can be a machine, a person who signs off, or an approval only one desk issues. The wait in front of that step lengthens as the points multiply, and on the day the step stops, every point stops with it. What grows is the number of places doing the work at the same moment; simultaneity is the quantity that matters, rather than the total amount of work a week contains.
A second device splits the work and leaves the dependency exactly where it was, because the work still waits on one piece of hardware being in order. Subtraction, not addition, is what scalability asks for here: the dependency ends when the step becomes something every point can carry out on its own. A purchase cannot do that; a design decision can.
In Vipkurum’s optical mark reading tool, a fault in the one central reader used to halt exam scoring for the whole institution; today each branch scores its own exam where it is. What replaced the device is traced in scoring exam sheets without an OMR device.
What went away was having to be in one place for the work to happen, and nothing more than that. A sheet filled in carelessly still reads badly wherever the reading happens, so the quality of the input stays a local condition. Taking out the single point is not the same as taking out every dependency.
When pages and records multiply, the structure must not be rebuilt
Addresses and rows are what multiply here, and the count was never the expensive part. What gets expensive is the character of the work: every addition turns into a small job for someone who writes code, and the additions arrive one after another. The job is drawing the page structure again by hand for each new location, period or category, which is only necessary where the structure was never settled against the breakdown.
The structure gets settled once against the breakdown itself: which breakdown keeps a permanent address, what that address shows, and which figures are read from which breakdown. Settle it and every further date and location falls into a mould that already exists, so the page structure stays independent of the count. That independence is what scalability means for this kind of growth.
On Günlük Hava Durumu every day of every location has an address of its own, and adding a location or a day leaves the structure of the site untouched. Why the pages get produced that way sits in how the site’s pages are built.
None of this applies to a brochure site whose page count stays put. An address structure built where no breakdown exists gives the site a mould it will never need to fill.
When the catalogue grows, the right answer is sometimes no new layer at all
If the record model took the growth that came without being rebuilt, and the work asked for no separate layer for searching or caching, a small stack counts as scalable too. The number of layers added measures nothing on its own. One test applies either way: was the growth absorbed, and was anything rebuilt to absorb it? A layer put in up front so that the system is ready for growth grows the surface to look after instead: an unused layer still gets updated, still gets watched, and still travels along at every move.
Get the model wrong and every new unit opens another row in the list, so the same thing repeats under slightly different names and the catalogue swells with its own duplicates. Get it right and the new unit lands underneath an existing record, where growth never shows up in the list at all. What grows in a catalogue is products and units; where it breaks is the record model.
One question tests this growth from the buyer’s side: whose job is it to add a new unit to the catalogue? If somebody has to tell the developer, every addition comes back as a small work order and the catalogue grows whenever someone finds the time; if your own team opens a record, the model is carrying the growth. Passing that test does not rule out layers, since some catalogues do need one.
At Kokudankokuya a new bottle size of the same scent does not open a new product in the catalogue, and at this catalogue’s scale the store carries no search layer and no cache layer beyond the application and its database. The variant line and where it falls belong to modelling product variants.
One answer does not fit another: what to ask when a proposal says scalable
An answer built for the number of institutions does nothing for a lengthening catalogue, and one built for working points does nothing for the number of pages. The four answers do not transfer: organisational growth is answered at the boundary, growth in working points by removing a dependency, record growth by a structure independent of the count, and catalogue growth in the record model. Side by side the distinction gets easier to hold, so the columns below carry what grows, where it breaks, what scalability means for that growth, and an example from work we built and still work on.
| What grows | Where it breaks | What scalability means here | Example |
|---|---|---|---|
| Organisations and tenants | A copy per organisation, where the number of copies is the number of things to maintain | A new organisation arriving as a definition, not an installation | Vipkurum |
| Branches and working points | One central step: a machine, a person or an approval; the wait lengthens and a fault stops everyone | Removing the dependency rather than adding capacity | Vipkurum optical mark reading |
| Pages and records | Redrawing the page structure by hand for every new breakdown | The structure staying independent of the number of breakdowns | Günlük Hava Durumu |
| Products and units in a catalogue | A wrong record model repeats in the list; a right one keeps growth out of sight | Adding no layer counting as an answer too | Kokudankokuya |
Four rows, and four different entries in the third column: that difference is the whole claim of this article. Read it across and the second column names the break the first column produces, while the third says what has to change for that break to go away. So the question to put to a proposal that says scalable is which growth the promise absorbs. Name one of the four and the conversation has something checkable under it; name none and the word is an adjective, while a figure for how many users the system handles can only be read once the growing thing has a name.
If a proposal on your desk calls a system scalable, the growth it has to absorb can be named with you before any code is written. That naming is the decision: the record model and the page structure get drawn around it, and a layer added later does not stand in for it. Where that decision belongs is set out on our system architecture page.
