> You never need that if these things are the result of a fixed client request; the set of things to be done can't change, so eventual consistency will serve the purpose.
Yes, if I wanted to handle orders of magnitude more simultaneous requests than this app could conceivably ever need to, but with more app complexity and greater latency for substantive results even at it's existing scale, I could use an EC solution instead of an ACID one, but...I don’t.
What are you getting out of ACID, and what is it costing you? The main practical effects of using an ACID datastore are that a) your writes don't commit until they've finished updating all your indices (sometimes what you want, but often not) b) if you get your dataflow wrong you'll get deadlocks, occasionally, probably starting weeks after you made the mistake that caused them
Yes, if I wanted to handle orders of magnitude more simultaneous requests than this app could conceivably ever need to, but with more app complexity and greater latency for substantive results even at it's existing scale, I could use an EC solution instead of an ACID one, but...I don’t.