The old database is switched off

Three changes over three evenings, Monday 24 to Wednesday 26 August. None of them waited for Friday.

Summary

Which parts fit which machine — Monday evening

What it is

When a customer asks whether a part fits their machine, that answer now comes from our main database instead of the old one. 147,323 records across six makes. This was the last question a customer could ask that still reached the old database, so after it nothing a visitor did touched the old system at all.

How we test it

Ask both databases the same questions and compare the answers, not the row counts. A load can be complete and still answer differently if something subtle drifted, so counting rows on its own proves nothing.

The evidence

Both databases held exactly 147,323 records. Across 150 sampled part numbers, the five different ways the store asks this question produced no differing answer between the two. The list of machines came back the same on both sides — 412 models each. It had also been running on the test copy of the store for three weeks beforehand, and the thing that proved the new path was genuinely in use rather than merely switched on was Kuhn: it answered zero there before Alex loaded the Kuhn data, where the old path would have answered 37,400.

Roll back or fail forward

At the time, roll back — one setting and a restart, a couple of minutes. That was deliberate: the old path was left in place for exactly this reason and removed only after this change had run for a day without complaint.

Orders, and the parts catalogue — Tuesday, eleven in the morning

What it is

Orders are now written to and read from our main database. The parts catalogue stopped using the old database entirely — not switched away from it, but disconnected from it, with the old code removed.

How we test it

Count the orders on both sides and then account for every difference by name. A count that matches tells you nothing about which side served it, and a count that does not match is only useful if you can say which order is missing and why.

The evidence

The old database held 47 orders, the new one 46, and the difference was one specific order placed on 23 August — named, not inferred, and it had not moved in two days. Alex copied that one across and reset the order numbering before the switch. That reset is his confirmation rather than our measurement: our own access to that database is read-only and is refused on exactly that operation, so it is recorded as his word and not as something we checked. Since the switch, orders are being written to the new database and none to the old.

Roll back or fail forward

At the time, roll back — put the previous version of each service back, both kept. That stopped being true the following day, when the old database was deleted.

Checkout let go of a database it was no longer using — Tuesday night

What it is

Checkout had stopped reading the old database days earlier, but it was still holding the door open to it and checking, every few seconds, that the door still opened. Switching the old database off would have made that check fail, and a failing check is how checkout decides it is not fit to take orders. This change removed the door.

How we test it

Ask checkout whether it is ready, and read the list of things it says it is checking. The list is the answer — not whether it says yes.

The evidence

Minutes before the change, checkout said it was healthy and listed the old database among the things it was checking, with a two-millisecond response. That is the whole finding: it was not using it and was still depending on it. Afterwards the same question comes back with the old database gone from the list and only our main database on it. That was read again this morning off the version currently taking real orders, so it is not a claim about what was deployed but about what is running.

Roll back or fail forward

Fail forward only, and deliberately so. The thing a rollback would have restored is the connection to a database that no longer exists.

What is kept — because the original is gone

A complete copy of the old database was taken four minutes after checkout let go of it, and before anything was switched off. It holds 66 collections across five databases — 453 MB, of which 452 MB is the live production data, 41 collections of it. It sits in long-term storage with no rule that deletes anything on a schedule, so it stays until somebody deliberately removes it.

It is the only copy. That is stated plainly rather than left to be assumed: there is no second backup elsewhere, and the system it came from cannot be asked again.

What v2.3.1 is — the exact thing to go back to

Read off the running systems on the morning of 26 August, after all three changes. Only the services moved; the storefront and search are still what v2.3.0 pinned.