I also agree with the later option. I've been using databases for a very long time. For the past 2 decades there has been a drive by framework providers to tr

I also agree with the later option. I've been using databases for a very long time. For the past 2 decades there has been a drive by framework providers to transparently handle such things and relieve developers of any difficult decisions. Often there isn't an option or it is deeply hidden. I've arrived on jobs to find Spring applications where database transactions have been unwittingly disabled (or not enabled) and no one has realised. There is also a lack of upfront thinking about types of data and the required consistency. Some items really should be consistent and some don't need to be. In one of Martin Fowler's earlier books he describes the difference between knowledge and operational data. Knowledge data is almost like configuration - perhaps the description of a currency and number of decimal places it has. Operational data might be an invoice generated using that currency. The description of a currency changes rarely (unlike a currency rate), it could be cached a long time for use by many processes without issue. However, the invoice must be consistent, but only one process will be involved in creating it and nothing else is held up waiting for it, and once it is created - it will never change. In practice most data items lie somewhere along this spectrum. However, you choose your tool and then everthing is either ACID or NoSQL.