Title: We run a small SaaS where users are able to create accounts, submit billing information and upload&#x2F;call ML artefacts.<p>In order to not reinvent the wheel we use external services where possible: Auth0 for authentication, Stripe for handling billing, etc. For this question, I am considering this a &#x27;microservices&#x27; architecture. I am aware that this definition will spark its own discussion, but I believe that the problem generalises to a lot of the other (better, more complete, etc.) microservice definitions. So please, bear with me.<p>Now, in the lifecycle of a customer (createAccount, addBilling, deleteAccount, ...) at various points we expect operations to occur atomically. By which I mean (simplified) that upon creating a new account, I also need to ensure a customer is created in Stripe as well as register the user in Auth0 - but if either of these subtasks fail, the operation (createAccount) should fail completely and in fact &#x27;undo&#x27; any state changes already performed. If not, I risk high-impact bugs such as double charging customers.<p>Now, in a &#x27;conventional&#x27; setup (without external services), I would resolve a lot of this by ensuring transactional operations on a single source-of-truth database. I understand that &#x27;idempotency&#x27; comes up a lot here, but whichever way I try to apply that here - it always seems to explode in a (fragile&#x2F;brittle) spaghetti of calls, error handling and subsequent calls.<p>Surely this has been resolved by now, but I&#x27;m having a hard time finding any good resources on how to approach this in an elegant manner. Concretely:<p>Do you recognise the problem of atomicity in microservices architecture?<p>And,<p>How do you deal with guaranteeing this atomicity in your microservices?
Upvote: