The First User Always Pays

On Tuesday I wrote about a database that accepted connections in two hours out of a hundred and eighty two. I called that the most interesting part and then moved on, so here is the rest of it.

That number is not a bug. It is what happens to anything used rarely, and the consequence is stranger than it first sounds: a system used twice a week is cold both times. Not usually. Always.

Warm is a property of traffic

Almost every performance optimisation underneath you assumes repetition.

Connection pools keep a connection open so the next caller can borrow it. Caches hold an answer so the next question is cheap. Runtimes compile hot paths after seeing them run. DNS results get reused. Sessions get resumed.

All of it depends on a next caller arriving before the last one's benefit expires. Traffic is what keeps those things alive, so a system with no traffic has no warm state to inherit. It is not that the code is slow. The code is fine. It just never gets to stand on anything.

The bit that should bother you

Now put the two facts together. Setup costs are paid by whoever arrives when nothing is warm, and rarely-used systems are never warm.

So the penalty lands exactly where you would least choose to put it. The admin dashboard someone opens during an incident. The quarterly export. The restore procedure. The break-glass path you built precisely because one day things will be on fire.

These are the paths where slowness costs the most and where it is guaranteed, because their rarity is the whole point. You do not use the emergency exit daily, which is why it is stiff when you finally push it.

Manufacturing traffic

The fix is not to make the code faster, since the code was never the problem. It is to stop the system from being idle.

Something on a schedule that touches the same path every few minutes will hold a connection open and keep the caches populated, which turns your first real visitor into roughly the tenth. It costs very little and it does not require anyone to change how they work.

It also pays a second time. A scheduled request that stops succeeding tells you something is wrong before a person finds it, which is the difference between a dependency you are watching and one you merely have.

Two honest caveats. Synthetic traffic is still traffic, so label it and exclude it from analytics, or you will spend a morning wondering who visits at exactly four minute intervals. And it makes idle billing slightly less idle, which is real but usually smaller than the cost of your own time.

The uncomfortable version is this. Your least used system is your slowest, your least observed, and the one whose failures you will discover last. None of that is because you built it badly. It is because nobody goes there, and nothing stays warm alone.