River redesigned their internal ledger system and API. They wrote a fairly detailed post about the process.
The previous data model was framed around the funds’ availability. We replaced that with a more precise model that tracks not only “how much”, but also “where” and “what kind”. Is the money sitting at our partner bank on behalf of the client, in transit, with one of our trading partners, something that we’re fronting to the client, etc.
I don't know much about rolling one database over onto a new one, but I found their approach interesting:
We made the decision to decouple the historical data backfill from the rollout of the new ledger. The standard playbook for data migrations is to: copy the old history, replicate the live delta to catch up, and when the lag is zero, pause writes and cut over. But we did it in reverse: atomic snapshot and cutover, replicate the live data, and independently backfill the history later.
The live replication could fail because of latent bugs in the new ledger, or the translation of legacy data could have issues and block the rollout. It was an open question whether the historical data could even satisfy all the new constraints and it could have taken weeks or months to finish successfully.
So, we decoupled these failure modes, allowing each to iterate and roll out in parallel. The trade-off was the extra machinery needed to do the cutover without pausing writes and having the backfill start from zero and mesh perfectly in the middle for each account.
And then they had to move all their historical data into the new system:
Backfilling six years of history was arguably the most challenging part of this project. It required consolidating data from ~40 tables into a canonical event stream that satisfies all the new constraints and meshes perfectly at each account’s cutover point.
Instead of using balance rules, we mapped historical data points as “evidence” for these legacy events. We tried our best to semantically match different states to our current superset of events which resulted in a much richer view of history than we originally had.
Mm, did Claude write their database migration? Looks like it.
If they did, how does it make you feel about their using their services?
I don't use them, but if I did, this would raise a few yellow flags for me.
I have nothing against people using AI, but an article or blog post that looks pumped out straight from AI with no human filter-pass raises yellow flags that they do the same thing with their code.
They had a staff coder position open about half a year ago. iirc it asked for an LLM adept though not a vibe coder per se. Not sure what to make of that but whatever... even the linux kernel is vibe coded now, there aren't escapes anymore. Just defensive waste of trillions of GPU ticks per minute because quality is in decline.
Either way... there's a reason why most finance systems have separate tables and a lot of duplication. Doing marketing about how you've optimized it all out, and got rid of balance rules is just... funny, and this post should have been in ~lol.
I wish I was savvy enough to have known to put it in ~lol
I suppose my savvy ends at not using River.
Haha. Wasn't criticism, I'm mostly just being grumpy.
I suggested looking at River to some 'normie-ish' US people that were just looking to DCA a bit of play money into bitcoin. I think I'd still do that if asked[1]. There are less complex ways to get rekt than through a vibe coded financial system.
or maybe I'd suggest cashapp first, but then, I spent half my day yesterday chasing a
squareup:wirebug I accidentally discovered its existence of through a review of other software that looked to be patching their dependency on it, that seems to still be under embargo but may touch half the shit I depend on. I'm not sure because... its embargoed - so no idea what's up. ↩'replaced our ledger' made me terrified for a second there... hahah
My first scan of the headline also thought it was a Ledger
😂