Re-think your data model and embed your transactions in a single account document so you get the document level atomicity that you need.
Interesting idea; I hadn’t considered grouping transactions because I assumed that it would become much harder to query data, but these examples seem promising.
Could this scale on a much larger set of data, say 10,000 or even 100,000 transactions? I assume document subdata like this can’t be indexed. It’s also hard to imagine that replication would work well with such a huge document size (I’m assuming it would have to calculate a full diff for each write).
The source of truth should probably be on your server / backend which has a more complete view of documents from all the clients. Even then, given that this is a distributed system, it may not be guaranteed to achieve atomicity across documents. But one option would be to expand your business logic to track deleted accounts and when transactions come in for deleted accounts, you delete those transactions.
I suppose this would be easier to do on the server side; the issue above where database.document(withID: "abc123") returns nil won’t happen on the server, but will instead have a _deleted: true property IIUC.
Though looking at the docs, it seems that Couchbase Lite 2.0 should also have _deleted tombstones, but that wasn’t the case from my testing as I mentioned. Are those docs correct?