A shared database is an anti-pattern in distributed systems.
Similarly, distributed transactions (ala. DTC) is an anti-pattern.
Distributed systems aren't hard. They're just different.
Then again, sometimes it's advantageous to identify parts of your system where aspects of state can be safely decoupled. And in which having them reside in disparate systems (and yes, sometimes be inconsistent or differently available) might actually be a better overall fit.
You completely lose the concept of transactional integrity, so you will have to work around that from the start.
Then again, sometimes your state changes not only don't need to be transactional; it can be disadvantageous to think of them that way.
Depends, depends, depends.
I'm curious; in what kinds of situation would this apply?
> Depends, depends, depends.
Flexibility is usually an important requirement. Often you cannot freeze your architecture and be done with it. I think a transactional approach could better fit with this.
Any situation where the business value of having your state be 100% consistent does not outweigh the performance or implementation cost of making it so.
The advantage though is that APIs (system boundaries) are usually better defined.
Perhaps one should use the best of both worlds, and run microservices on a common database, and somehow allow to pass transactions between services (so multiple services can act within the same transaction).