Hacker News Reader

Comment by lintfordpickle | Hacker News Reader

I found the article interesting, but I don't think I understand what is meant by 'Write Last, Read first' rule - even after reading it a few times. It seems to be too ambiguous a statement to be helpful.

Under the section 'Order of Operations':

> "Since the system of reference doesn’t determine existence, we can safely write to it first without committing anything. [...]"

Then the next paragraph

> "This principle—Write Last, Read First—ensures that we maintain application level consistency."

What I think it means is, 'writing-last to the system-of-record' and 'a read-first from the system of record' yields authoritative results, but I don't get that just from the title. Is my understanding correct?

View on HN

Yes, write last to the system of record, read first from the system of record. Or in other words, commit to the system of record, and then read from the system of record to see what's committed.

(This is similar also to how chain replication preserves consistency.)

If you read first and write last isnt that the opposite of committing and then reading to see what is comitted?

I think they just reinvented 2-phase commit? I'm not sure either tbh.

No, in two-phase commit all target systems perform two phases (staging the commit, which may fail, and then actually committing it in a failsafe way), which isn’t the case here.

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.

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.

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.

Not sure why this was downvoted, the comment is completely right.

Reply on news.ycombinator.com