| ▲ | scripturial 14 hours ago |
| 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 14 hours ago | parent | next [-] |
| Ah time to repost the classic: https://stackoverflow.com/questions/16833100/why-does-the-mo... |
|
| ▲ | blibble 14 hours ago | parent | prev | next [-] |
| 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 12 hours ago | parent [-] | | 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_ 11 hours ago | parent [-] | | 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 14 hours ago | parent | prev [-] |
| Where did you get the idea that “append only” needs to necessarily be implemented at the database layer? |
| |
| ▲ | scripturial 14 hours ago | parent [-] | | 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 14 hours ago | parent [-] | | 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 14 hours ago | parent | next [-] | | Not necessary or sufficient, but with append only model you can at least trace back what has happened if/when something goes wrong | | |
| ▲ | Terr_ 10 hours ago | parent | next [-] | | 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 13 hours ago | parent | prev [-] | | 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 14 hours ago | parent | prev [-] | | 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 14 hours ago | parent [-] | | 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. |
|
|
|
|
