4 ms·

It's how banks work. You write a check and buy something. The banks reconcile and determine you don't have enough money, and your account goes negative. If i

• meddlepal 9y ago
  I knew I'd see this in the comments. Yes it is how banks work, but I hate how this comment usually plays (and I'm not accusing you of this) into "It's good enough for banks therefore it's good enough for us" arguments. Banks have a really special set of historical and regulatory availability constraints that most systems do not deal with, not to mention, time constraints across the globe. If your business process can handle lag via auditing and reconciliation processes then by all means adopt EC, but I'm not sure that plays out as much as engineers reach for the EC toolbox.
  • lojack 9y ago
    > If your business process can handle lag via auditing and reconciliation processes then by all means adopt EC, but I'm not sure that plays out as much as engineers reach for the EC toolbox. Not sure I agree with that. I'd argue that there's very few (if any) businesses that are strictly consistent. Sure, there may be pieces where consistency is important, and eventual consistency isn't a silver bullet you can fire and forget, but its uncommon to see entire systems modeled in a strictly consistent manner. This past year I've built a number of apps to support both core products as well as internal initiatives, and I don't think a single one was strictly consistent. There were parts of the apps that needed consistency, but as a whole they were pretty much all eventually consistent. What's important is that you understand when strict consistency is necessary, and when it can be relaxed, and that you understand when your operations are eventually consistent and when they aren't.
    • dijit 9y ago
      Your comment would only need minor rephrasing to be a defense of C++/C code for greenfield projects in 2017. "You can be smart about when to use it, if you're good you'll know when you need it"- I personally feel that this is a dangerous default.
• flukus 9y ago
  It's how banks the 20th century worked with external systems (people in this case), I bet they were transactional internally once they were computerized. In the 21st century, if I buy something at a shop and there are not sufficient funds in my account the transaction is canceled and I walk out of the shop empty handed. The non-transactional system is still there as a fail over.
  • di4na 9y ago
    Except no. They are transactional in the small. But the system itself is still eventually consistent. There are just too many transaction that ends up with a false positive or a false negative. Plus ebery you do a transaction, you have up to 60 days to cancel it. You will get your money before that.
  • snarfy 9y ago
    This is not true either. All modern POS systems have an offline mode. Have you ever tried to use your card and the employee says 'the machine is really slow today'? That's because the machine was offline, but your purchase still worked. In offline mode the POS will still authorize the purchase up to a certain amount, typically $75 (up to the store). Those charges are pushed through after the machine goes online. Yes, it's a failover, but the point is even the modern online system is still not atomic and has eventual consistency. Legitimate purchases outnumber illegitimate purchases by a large factor. It makes sense to err on the side of legitimate purchases. If it were atomic you wouldn't have been able to make that offline purchase, even though you had the money. Since it's true in the majority of cases they let those go through, up to a certain risk factor (the $75 limit).