What reliability means for a small business system

If the connection drops at 19:40 on a Thursday with six people at the counter, the useful question is not whether the site is up. It is whether the till can still take money, and what happens to the sales recorded while nobody could reach the server. Reliability is decided in that hour, not in the monthly average.

Uptime is the wrong measure

A system can be available all month and still be unreliable, because the two things people mean by the word are different. Availability is a percentage someone reports. Reliability is what a failure costs and how long it lasts.

Three questions set the target better than a number — and a system where nothing may fail costs more than the business earns:

• What must keep working when nothing else does? Usually one thing: taking money, or recording that a delivery left the warehouse.
• How much recent data can be lost before you are lying to a customer? A cash total can be recounted; a signed delivery note cannot.
• Who is woken up, and what are they expected to do? If the answer is "nobody, or the developer if he answers", that is the reliability level, not the server.

The counter has to keep selling

In a shop, the sale is the one transaction that cannot wait. An invoice can be reissued, a stock count corrected, a report a day late. A sale is cash in a drawer with a person in front of you.

Keeping that working is less about hosting than about where the data lives:

• price and stock for what is on the shelf must be readable from a local copy, not fetched at the moment of sale;
• the sale is written locally first and transmitted afterwards, so the record exists before the network does;
• every write carries an identifier generated at the counter, so a retry after a timeout cannot produce two invoices for one customer;
• the queue is reconciled when the connection returns and reports what it could not send;
• stock has exactly one owner.

That last point causes more incidents than any hosting decision. If the till and the server both believe they know the stock, the first disconnected afternoon produces two truths. The offline requirement is not mainly a synchronisation feature; it is a question about who is allowed to decide.

One owner for each fact

A price. A stock level. A customer's balance. Each of those is a fact, and each may have exactly one place that decides it. Everything else asks.

Feature-by-feature building breaks this quietly. A login page. A stock screen. A report. Each one works, and the system as a whole has no structure — only parts that happen to sit near each other. The damage arrives later as duplicated state, rules spread across screens and endpoints, one edge case handled two ways. Then a requirement changes and the change ripples through modules that each had an opinion about what stock means.

The design rule is unglamorous: know which module owns each fact, make the others ask through an interface rather than reading its tables, and let data flow in one direction. It costs time at the start and feels slower than it is. It is also what makes a disconnected day recoverable.

A backup is a copy you have restored

A file nobody has opened is a hope.

Backups fail for boring reasons: the job pointed at the wrong directory, the disk filled, the credentials expired, the database was included but the uploaded documents were not. None of it shows until the day you need it.

What to check before you trust one:

• it is not on the same disk, host or account as the data it protects;
• it includes the files as well as the tables — signed invoices, photos, scanned documents. Without them you restore a system that lists documents it does not have;
• its retention covers the mistake: if a wrong price is found three weeks later, a week of history does not help;
• someone other than the person who set it up can restore it, from written steps.

Then do the drill once, before you need it:

1. Restore to a machine that is not production.
2. Restore the database and the files together, in the order the steps say.
3. Answer a question you already know the answer to: yesterday's cash total, the last invoice number, one customer's balance.
4. Time it, from the first command to that answer.
5. Write down what was missing.

The duration from step four is the only recovery figure worth quoting, because it is measured rather than promised. Everything else is a wish with a date on it.

What 2am actually requires

Monitoring and being woken are different products: a dashboard is where you look after something has already gone wrong, and it does not get anyone out of bed. For a small system, three things decide the night:

1. The fault reaches a person, not a screen nobody has open at 2am — usually a message to a phone, and a second person if the first does not answer.
2. That person has a written first move. Not a diagnosis — a first move: "check whether the counter is still selling; if it is, this can wait until morning." Most night faults need a decision, not a fix.
3. The escalation says what can wait. "The counter cannot sell" and "last month's report is wrong" should not wake the same person at the same hour. If everything is urgent, nothing is.

A business may also decide, deliberately, that nothing wakes anyone: the system is down until the shop opens and staff know the paper fallback because they have practised it. That is legitimate and cheap. What is not is finding out at 2am that nobody decided anything.

The order to fix things in

Most reliability money is spent in the wrong order. This sequence covers more incidents per hour:

1. Name what must never stop, and what it physically needs: a local copy of prices, a working printer, a phone the counter can reach.
2. Give each fact one owner. Stock, price, balance. Nothing else decides.
3. Restore one backup and time it. Fix whatever the drill exposes.
4. Make failure reach a person, and write down the first three steps they should take.
5. Keep the previous version runnable. A deploy that cannot be undone is the usual way a working system stops working on a Friday evening.
6. Only then buy redundancy. A second server, a standby database.

Steps one to five cost time rather than licences and cover the incidents that happen. Redundancy is often bought to avoid a conversation about steps two and three.

Where this advice stops

This is written for systems where a failure costs money in hours: a till, an order desk, a booking sheet, a warehouse scanner. It does not transfer to anything where a failure costs safety, and nothing here is guidance for medical, industrial or transport control. It also assumes the system is not already failing every day; if it is, the next step is an incident, not a design debate.

It says nothing about how long you must legally keep records. Those obligations are set by your accountant and tax authority, usually far longer than any technical default, and restoring last week does not prove you can produce a document from four years ago.

And cloud is a location, not a reliability property. A managed database with no restore drill is exactly as unrecoverable as a local one, with a monthly invoice attached.