[MuffinFlavored]

> For many applications, it's easiest to start with a modular monolith talking to a shared database, one that natively supports transactions.

I don't think this handles "what if my app is a wrapper on external APIs and my own database".

You don't get automatic rollbacks with API calls the same way you do database transactions. What to do then?

[natdempk]

You have a distributed system on your hands at that point so you need idempotent processes + reconciliation/eventual consistency. Basically thinking a lot about failure, resyncing data/state, patterns like transactional outboxes, durable queues, two-phase commit, etc etc. It just quickly gets into the specifics of your task/system/APIs so hard to give general advice. Most apps do not solve these problems super well for a long time unless they are in critical places like billing, and even then it might just mean weird repair jobs, manual APIs to resync stuff, audits, etc. Usually an event-bus/queue or related DB table for the idempotent work + some async process validating that table can go a long way though.