When the answer is not a bigger server
Marketplaces and platforms rarely fall over. They get slower, and the first remedy offered is always more hardware. Why that postpones the problem, where the time actually goes, and how to tell when the platform genuinely has to change.
Marketplaces rarely fall over. They get slower, a little at a time, until somebody notices that search takes four seconds on a Monday night and customers have started leaving before the results arrive.
And the first remedy offered is almost always a bigger server. It works, briefly, which is the problem: it buys time in proportion to what you spend, while the thing actually causing the slowness carries on getting worse underneath.
Why more hardware hides the problem
Most marketplace slowness comes from a small number of database queries that examine far more data than they need to. When the catalogue was small, examining everything was fast enough that nobody noticed. As listings grow, the work those queries do grows with them, and a faster machine simply does the unnecessary work more quickly.
A bigger server does not fix a query that reads the whole table. It just reads the whole table faster, until it cannot.
This is why the upgrade feels like a fix for a few months and then stops. The cost is permanent and monthly; the relief is temporary.
Where the time usually goes
| What it looks like | What it usually is | |
|---|---|---|
| Search and filtering | Fine with a few hundred listings, painful with tens of thousands | Queries with no usable index for the way people actually filter, so the database scans instead of looking up |
| Listing and category pages | One page loads slowly and the delay grows with the number of items shown | A page that runs one query for the list and then another for every item in it, so thirty results mean thirty-one round trips |
| Images and media | Pages feel slow on mobile even when the server responds quickly | Full-size images sent to phones, served from the application rather than a content network |
| Everything, at peak | Fast most of the time, unusable at the busiest hour | Nothing cached, so identical work is repeated for every visitor at exactly the moment it is most expensive |
Measure before you change anything
The slow page is rarely slow for the reason people assume. Before touching indexes, hardware or code, find out where the time is actually spent: which queries run on the page, how long each takes, and how often it is called. An afternoon of profiling regularly replaces a quarter of guesswork, and occasionally shows that the expensive page is not the one anybody complained about.
It also protects you from the most common own goal in this work: adding indexes everywhere. Every index speeds reads and slows writes, and a marketplace writes constantly. Indexes should be added deliberately, to serve queries you have measured.
Caching is not one decision
There are several places to cache and they solve different problems: in the visitor's browser, at a content network near them, in your application, and on the results of individual queries. Getting the layer wrong either achieves nothing or serves somebody stale prices.
Two-sided marketplaces are harder than most sites here, because much of what looks like a public page is not quite public: availability changes, prices vary, and what a buyer may see depends on who they are. That is exactly why the naive approach of caching whole pages tends to be abandoned after one embarrassing incident, and why the useful work is usually caching the expensive parts underneath rather than the page itself.
Know before your customers do
Most performance problems arrive gradually. A release adds two hundred milliseconds, then another, and nobody notices until the total is intolerable. Without monitoring, the first report comes from a customer, by which point the cause is buried under three months of changes.
Tracking response times for your handful of important pages, and alerting when they drift, turns a slow decline into a specific release you can look at. It is the cheapest thing on this list and the most consistently skipped.
When it genuinely is the platform
Sometimes the model really has moved on: what was built for one kind of transaction is being asked to carry three, and every new feature fights the original assumptions. That is a real situation and no amount of tuning resolves it.
But it should be a conclusion rather than an opening bid, and it is a conclusion you reach from measurement. Rebuilding is the most expensive recommendation anybody can make, and in this area it is frequently offered before anyone has looked at a single query.
The short version
If growth is making your platform slower, the cause is usually a few queries doing far more work than they need to, and hardware only postpones it. Measure where the time goes, fix the causes in the right order, cache the expensive parts rather than whole pages, and put monitoring in place so the next decline is visible while it is still small.
Paying more each month for the same slowness?
Tell us what your platform runs on and where it hurts. The Health Check is fixed-price and read-only, and it finds the cause rather than the symptom.
Why audit preparation takes a fortnight
For NDIS and care providers, audit pain is almost never about the care delivered. It is about evidence that was never captured in one place, and a process that lives in one person's head.
The gap between finishing a job and invoicing it
In field operations the invoice waits on a job sheet travelling back to the office in a vehicle. Why capturing work on site fixes both the lag and the disputes, and why scheduling is the wrong place to start.