> With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late.

I don't follow your reasoning. I mean, the ACID vs BASE problem you described is extensively covered in pretty much any microservices 101 course or even MOOC, along other basic microservices tradeoffs such as the distributed tax and ways to mitigate or eliminate these issues like going with bounded contexts. Why do you believe this is a mystery that no one is aware of?

I've seen a couple of projects where the original team didn't think they needed transactions, or underestimated how much harder eventually consistent distributed systems are to reason about than an acid system.

It doesn’t matter if you have transactions or not. Just make sure you execute things in the right order! Same for referential integrity, if you just make sure nothing ever goes wrong, there’s no need for it! /s

Could you elaborate what you mean by transactions?

Sequences of interactions with the DB which are either atomically committed to on success of the sequence, or rolled back on failure, so that the DB is in the same state it had before the interactions began.

Can you explain why you lose that ability? It's not obvious to me.

One of the fundamental laws of microservices is that each service is responsible for storing its own state. Nothing else is allowed access to its backing store.

Given that, once you have more than one service in your architecture, you cannot coordinate transactions across the distinct storage mechanisms - they are distinct databases and are therefore subject to the CAP theorem and other complexities of distributed computing.

Of course, nothing's stopping you from putting all your features into one service to avoid this thorny problem. It's a wise approach for most of us.

When you do that you have a monolithic architecture, not a microservice one.