[scripturial]

I wonder if use of MongoDB creates a legal liability. I’m not up to date on the architecture of MongoDB but I am under the impression that it couldn’t be reliably used for this kind of thing?

(The problem here is not nosql, I believe you can do reliable accounting with ScyllaDB and Cassandra as long as you design things correctly. Basically only ever allow append/add but never allow update/delete. I’m not sure if this is true of MongoDB.)

[rvba]

Ah time to repost the classic:

https://stackoverflow.com/questions/16833100/why-does-the-mo...

[blibble]

and this is why I insist on still having paper bank statements

when the k8s+mongodb "non-legacy" tech stack implodes at least I have a physical document the bank produced that the court can understand

[orev]

Or at the least, download PDF statements every month. I fear that if too many people don’t do that, eventually they’ll remove that feature due to low demand.

[Terr_]

I would be ecstatic if my bank allowed me to generate (and revoke) a set of API credentials that were narrowly permitted to download transaction/statement data."

Alas, for many people the "workaround" is to put their credentials into a third-party service, and the fact that such things exist make me think I'm taking crazy-pills. [0]

[0] https://www.youtube.com/watch?v=fRL80YB0x3s

[lxgr]

Where did you get the idea that “append only” needs to necessarily be implemented at the database layer?

[scripturial]

No one said that.

The point is it’d be hard to loose data with Scylla as long as your only ever appending to the physical tables. I don’t know if MongoDB has this same attribute.

[lxgr]

No idea, but why would that be necessary or sufficient to make it very unlikely to lose data?

Things can go wrong on many layers above and below the database, so the property you describe seems like an implementation detail of one particular approach, not something fundamentally necessary for sound bookkeeping.

[Kkoala]

Not necessary or sufficient, but with append only model you can at least trace back what has happened if/when something goes wrong

[Terr_]

If they were recording all the necessary information there in the first place, anyway. The level of detail to replay or audit is usually higher than whats needed for direct operation, especially if some things go out through remote systems/accounts and back.

[lxgr]

Sure, but you can have your append only layer be provided by a core banking system, and have your applications communicate with that using a higher-level protocol.

I don't see what would inherently disqualify Mongo from being the backing layer for that core banking system then.

[scripturial]

I am not sure where the disconnect is. Having a database that can provide a permanent unalterable record of all transactions, even when running over a distributed network, seems reasonably important to me.

Are you saying it’s just as good to do this in the application layer? I respect that’s a possible option. Not sure I agree it’s a good option.

[lxgr]

That's exactly what I'm getting at. You'll want one layer in charge of ensuring consistency and authentication of incoming write requests.

This can be, but definitely doesn't have to be, a typical relational database in conjunction with a core banking system.