1. 1
  1.  

  2. 4

    One does not need ACID to solve the problem the author describes and ACID is likely overkill for the issue. There are other options such as causal consistency or RAMP transactions which are much light than ACID but still strong than eventual consistency.

    But the author is spot on in that transaction boundaries are a big problem that groups either ignore or don’t address in their design.

    Pet peeve though:

    but I think you will find that they all have issues, and none are simpler or easier than an ACID database

    and

    ACID transactions are usually simpler than eventual consistency or distributed transactions

    1. Simpler in what regard? Production ACID transactions are very complicated to implement, they require a lot of machinery. They also put a lot of constraints on the data. And they can fail in surprising ways. EC is extremely simple but it pushes complexity to the user. So a blanket “X is simpler than Y” statement here doesn’t make much sense IMO.
    2. ACID transactions can be distributed transactions to the second quote is a bit confusing.
    1. 2

      Thanks for the feedback. I have never heard of RAMP transactions before, so I’m definitely going to read up on that. Right now I don’t see how the problems can be solved without the A, C and I of ACID though.

      I could soften the wording a bit. What I’m actually rallying against is pushing the complexity of transactions to the application code, instead of handling it in the database.

      You’re right about #2. I’ll update the article.

      (changes here: https://github.com/KMahoney/kmahoney.github.io/commit/605ae0c11a73fcf7e1ffe717d08d8c803a6dd3be)

      1. 1

        Right now I don’t see how the problems can be solved without the A, C and I of ACID though.

        That doesn’t necessarily mean you need the rest of ACID, though. And the rest of ACID is prohibitive. Separate services owning related data, for example, is very difficult if-not impossible. With causal consistency you can spread data out over multiple services and as long as they offer the data semantics needed (and you’re ok spending the bit of extra cost to implement it) it’s not a problem.

        The key observation, IMO, for causal consistency or RAMP transactions is that the actual data in the DB doesn’t need to be consistent, you just need to be able to find a consistent version of it. So if you create/updated data in one place you need to either update it the other place or make sure you can get the state of data pre-update in both.