3 ms·
> And obviously you choose availability for the distributed systems you most commonly encounter. fail safe (rather than fail open) is generally regarded as the
by dijit 2y ago
> And obviously you choose availability for the distributed systems you most commonly encounter.
fail safe (rather than fail open) is generally regarded as the most acceptable thing we can do as CRUD programmers; that’s true, however it’s categorically untrue that this is a foregone conclusion.
There are many cases (especially in financial services) were failing safe is a much preferable option and having retry logic in application is much preferred
- stevebmark 2y agoIn distributed banking back-ends, if one of your datacenters goes down, you don't take down the other one for safety. You don't force global consistency/linearity of all transactions before allowing UI updates. There are delays in financial reconciliation all the time, the important thing is they are eventually consistent with a ledger, not that if one thing fails, you stop the train. And the reality of distributed systems is things fail constantly. Hard drives, networks, bugs, clock drift... This is in contrast to something like a supercomputer, or a distributed map-reduce job, where if one node fails as part of a distributed process, it will corrupt your data, and you have the luxury to stop the whole thing, fix the issue, and restart the whole process.