SSerguey Asael Shinder
Java coding notes: the JVM, and writing software that lasts

Serguey Asael Shinder: Run the new store as a readable second copy before you make it the record

· by Serguey Asael Shinder / Serguey Shinder

A news item on 30 September caught my attention for a reason that has nothing to do with blockchains. CSD BR, a regulated Brazilian depository, started recording ownership of some BTG Pactual funds on the XRP Ledger, and CoinDesk's report stresses one design decision: the depository's existing database remains the official record. The ledger is a second copy that approved banks can read and compare with the database at any moment. Issuing assets directly on the ledger is a later step, to be explored after the mirror has run on live data.

That is the order I have come to prefer for any migration of a system of record, whether the new home is a database, a service or a vendor platform.

Write to both, trust one. The old store stays authoritative. The new one receives every change, from the same events, but nothing reads from it for decisions yet.

Serguey Asael Shinder: Run the new store as a readable second copy before you make it the record
Run the new store as a readable second copy before you make it the record — Serguey Asael Shinder

Make the comparison continuous and visible. The value of the mirror is not the copy, it is the diff. In the Brazilian case, every change on the ledger is public, including reversals, so a gap between the two records would show. In an ordinary migration the equivalent is a reconciliation job that runs all the time, counts mismatches and alarms on them, rather than a one-off check before the cut-over weekend.

Let other people read the copy. The depository lets the banks that consume the data read the new record directly. Internally, that means letting the downstream teams query the new store in shadow while the old one still answers for real. They find the differences you did not think to test for, because they know what their numbers are supposed to be.

Switch authority only when the diff has been boring for long enough. "Long enough" should include month-end, a release, and whatever unusual event your domain has. The switch itself then becomes a configuration change, and the old store becomes the mirror for a while, in case you need to go back.

This is slower than a big-bang cut-over, and it costs double writes for a period. What it buys is that the day the new system becomes the record, it has already been wrong in front of you, and fixed, many times. I would rather pay for that than discover the first mismatch after the old system is gone.