this is an immensely reassuring, and at the same time motivating comment

I think the point of the article is not whether the tracking apps are relevant - or damaging to privacy, which they very well may be. The point is that these decisions should be made by European governments, nót (American) corporations.

eh, a vaccine becoming available in the next year or two?

That is the only hope in my mind. But the government can't pay for everyone to stay home all that time. Hyperinflation is a terrible thing and it comes when governments start printing money wildly.

Thanks, really appreciate the pros and cons here. To be clear, and I understand the confusion: I'm actually building more or less a monolith with a RDBMS to encapsulate most of the business logic of my problem domain.

However, for various parts of my application that seem high-complexity, high-impact and non-competetive edge (such as authentication and credit card handling) I want to outsource to external services (Auth0 and Stripe). This brings with it the challenge of managing state, and consistency across various external services (on top of the state I manage internally).

The reason microservices is mentioned in the question, is because I believe these problems generalise from my specific case, to microservices.

I like this approach: it closely matches my initial instincts of having a 'transaction' table for each type of event, with columns for each of the steps. The reason I'm weary of this approach, is because I have done an implementation of this in the past but it turned out to become a nightmare - this is most likely due to a combination of the complexity of that particular domain, my inexperience with this type of problem and external pressures.

I did find some pretty good resources on Sagas - do you have any thought on comparing Sagas pro/cons vis-a-vis this approach?

I do not know much about sagas.

I like this approach because you need this user table anyway (probably!) and no data is duplicated in your system. There is one authoritative place that maps username to stripe id, and the logic to work on computing that (making stripe api calls, retrying) lives inside the system that is responsible for telling other parts of your infrastructure that ID. So you do get a consistent view from everywhere; no system will ever have the "wrong answer".

The complexity here comes from handling every possible transition. With an ad-hoc approach, some transitions are hidden and can be ignored until they actually happen. With this approach, you have to think about it all up front and write the necessary unit tests.

The first version of my password changer thing detected states I hadn't thought about and just sent an alert for someone to manually do something. There was a control plane outage and everything broke one day, and that forced me to implement some of the automatic cleanup. Some other comments suggest "don't write this, just send your ops team an email when something breaks" and that is fine for the initial version. All you really want is a detailed record of what's happened and what went wrong, from there you can either fix it one-off, or finally write the code to fix it automatically. You don't need to implement retries and rollbacks on version 0... just flag the account and go fix it yourself until you decide you'd rather have the computer do it.

So you would recommend implementing authentication and handling credit cards from scratch? The reason I'm going with this approach is because although I do use a monolith and a single (hosted) DB for my business logic my understanding was that implementing high-impact, high-complexity (non competitive advantage) systems like authentication and credit card handling are best 'outsourced'.

This outsourcing of high-impact, high-complexity does come with the disadvantage of now having to deal with external services. As far as I can tell, the atomicity/transactional problem with these external services generalises to microservices - hence the microservices tag.

No of course not.

You have third party thing working like authentication. Bake that into your application in a simple flow where if it works the user gets added to the database or gets access etc to things. Then you would be able to use transactions in the DB

thanks, useful resource!

Thanks. From my (limited) understanding this sounds a lot like the Sagas that have been suggested by others - does that match your intention?

This approach makes a lot of sense. I was unaware of the concept of idempotency keys (nor did I know Stripe supported them). I'm actually trying to avoid complexity, which is why I turned to Auth0, Stripe (i.e. external services) to handle most of the logic for me - I'm sure I just need to figure out how to correctly apply those! Thanks for your input!

The way I have tried to implement (very likely, shoddily) idempotency is to have each mutation on an external service (say creating a customer in Stripe, corresponding to an account already administered in my database) first check if a customer with that ID already exists, and if not to create it - otherwise use the existing object (Stripe customer in this example).

``` user = Database.get_user(my_user_id)

if (Stripe.customer_exists(user.id) { return Stripe.get customer(user.id) } else { stripe_customer = Stripe.create_customer(user.id, user.email) Database.set_user_property("stripe_customer_id", stripe_customer.id) return customer } ```

The problems here are multiple, but at the very least I see the possibility of very nasty bugs if somehow the `customer_exists` call returns a false negative - this will cause the same customer to be created in Stripe twice (and thus potentially be charged twice). Another, more likely, issue is that between the `Stripe.create_customer` call and the `set_user_property` there may be an unexpected event (service/network goes down, whatever) failing to store the property - leading to a duplicate Stripe customer the next time the above code is executed. On top of that, I find it pretty difficult to reason about a code base chock full of this type of logic (perhaps that is just my personal limitation though!).

That's it! Not sure how I never stumbled upon this. Thanks!

Came here to say same thing. Saga pattern is the way to go.

Also, suggest you to carefully think about transaction boundaries, if possible, prefer eventual consistency over transactions.