in this day and age, are there more useful concepts that we could be giving more attention than CAP, ACID, and friends? Are they useful enough to satisfy the dfsdt principle? I think not.
CAP is useful to the extent that:
- people consciously declare that they have beaten it (in which case you have a very strong launchpad for your rebuttal, e.g. "Are you just pretending P won't happen?")
- or that they are sleepwalking into a software design which implicitly requires CAP capability to function well (in which case you know ahead of time that it will not function well, and so you should choose a different design).
ACID is a useful shorthand for "Can I rely on single-threaded reasoning while writing this multi-threaded program?" E.g. If I transactionally subtract 5 over here, and add 5 over there, then my code will not have changed the total amount. Since we now know DB vendors operate by default in a weaker isolation mode, we have a shorthand for knowing we can't use use single-threaded reasoning, and instead need to consider which commits over there will change the state of the running transaction over here.
- people consciously declare that they have beaten it (in which case you have a very strong launchpad for your rebuttal, e.g. "Are you just pretending P won't happen?")
- or that they are sleepwalking into a software design which implicitly requires CAP capability to function well (in which case you know ahead of time that it will not function well, and so you should choose a different design).
ACID is a useful shorthand for "Can I rely on single-threaded reasoning while writing this multi-threaded program?" E.g. If I transactionally subtract 5 over here, and add 5 over there, then my code will not have changed the total amount. Since we now know DB vendors operate by default in a weaker isolation mode, we have a shorthand for knowing we can't use use single-threaded reasoning, and instead need to consider which commits over there will change the state of the running transaction over here.