Remix clone Hacker News

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 13 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.