4 ms·
There's also the issue of sometimes needing actual strong consistency. Things like auth or billing for example where you absolutely can't tolerate eventual cons
by Nextgrid 1y ago
There's also the issue of sometimes needing actual strong consistency. Things like auth or billing for example where you absolutely can't tolerate eventual consistency or split-brain situations, in which case you need one region to serve as the ultimate source of truth.
- kassner 1y ago> billing […] can't tolerate eventual consistency Interesting point that banks actually tolerate a lot more eventual consistency than most software that just use a billing backend ever do. Stuff like 503-ing a SaaS request because the billing system was down and you couldn’t check for limits, could absolutely be locally cached and eventual consistency would hurt very little. Unless your cost is quite high, I would much rather prefer to keep the API up and deal with the over-usage later.
- chmod775 1y agoBanking/transactions is full of split-brains where everyone involved prays for eventual consistency. If you check out with a credit card, even if everything looked good then, the seller might not see the money for days or might never receive it at all.
- smj-edison 1y agoInterestingly, TigerBeetle manages to have distributed strict consistency over 6 machines.
- mdavidn 1y agoBanking is full of examples of eventually consistent systems. ACH, credit card transactions, blockchain...