[withinboredom]

You’re thinking too concretely. What do you think you’re doing before you write “to the source of truth”? You’re staging the commit. And then you commit.

2pc isn’t literally about transactions like you are probably thinking of in a database, its an abstract “atomic change” or “unit of work” that may or may not involve a database or a database transaction. You can do 2pc with just normal files, or APIs, or whatever.

[layer8]

I disagree. The definition of a two-phase commit protocol is that you have a number of participants in a transaction, and the first phase consists of asking each participant if they can commit, and if or when all participants affirm positively, then the second phase consists of telling all participants to perform the commit. Let’s not dilute well-established terms.

The procedure in the article is not a two-phase commit, because changes are committed to the system of reference regardless of whether the subsequent commit to the system of record succeeds or not.

In addition, half of the rule in the article is about the ordering of reads, which two-phase commit isn’t concerned about at all.

[withinboredom]

It’s just moving this into the application level, but it’s still 2pc.

Intent: Begin the durable execution (i.e. resonate.run)

Prepare: Write to the system of reference -- safe to fail here.

Commit: Write to the system of record -- the commit boundary.

Ack/Recovery: checkpointing + idempotent replays.

Abort/Compensation: panic or operator intervention.

Ordering operations has always been a thing you should do. And they’re treating this as a distributed system to simulate an ACID transaction. For example, if you ever do locks of multiple things, the order you take the locks has to be the same across the entire system so that you never deadlock. If your database is taking locks, then order matters there too. They rediscovered what us in the distributed systems world have always known and fairly well-documented: ordering is how you simulate time and prevent paradoxes.