[HN Gopher] The write last, read first rule
___________________________________________________________________
The write last, read first rule
Author : vismit2000
Score : 91 points
Date : 2025-11-11 06:30 UTC (16 hours ago)
(HTM) web link (tigerbeetle.com)
(TXT) w3m dump (tigerbeetle.com)
| jorangreef wrote:
| Joran from TigerBeetle!
|
| Happy to answer any questions. And thanks to Dominik Tornow of
| Resonate for writing this up as a guest post! It was a little
| rule we had coined, to help people remember how to preserve
| consistency across different DBMS's, and I think Dominik gave
| (beautiful) voice to it.
| xmcqdpt2 wrote:
| IMO the example about checkpointing is not that demonstrative
| because creating entities is easy to make idempotent. What
| about transactions? Do they need idempotency and if so, how
| does it work?
| layer8 wrote:
| I concur with https://news.ycombinator.com/item?id=45886850,
| the article doesn't actually spell out what the "Write Last,
| Read First" rule is supposed to say. The name of the rule also
| isn't great, because it leaves open _what_ to write to /read
| from, and doesn't even suggest that there might be several
| systems to write to/read from, which however is essential to
| the rule.
| jorangreef wrote:
| The _what_ here is the "system of record". There might also
| be no other systems to write to /read from--and that's fine.
| The important thing is the order. Hopefully "Write Last, Read
| First" is unforgettable in that respect!
|
| Or, can you suggest something pithier?
| layer8 wrote:
| The article mixes two things: (1) That you should
| (depending on requirements) have one system of records
| while the other systems are merely systems of reference,
| and (2) that in that architecture, when (*) you write to
| both systems or read from both systems for the same logical
| record, then in the writing case you have to write to the
| system of records last, and in the reading case you have to
| read from the system of records first. The article however
| doesn't make it clear that the titular rule is specifically
| (2), and that it is conditioned on (1) and on (*).
|
| I have no suggestion for a better name off the top of my
| head. The issue I see is that you already have to know well
| its context and when it applies, also in order to not
| misremember it as "Write First, Read Last", and to not
| mistake it as LIFO, or to relate it to a read-modify-write
| scenario in which you naturally would read first and write
| last anyway, though in a different sense. You see how the
| name is confusing?
| jorangreef wrote:
| I'm not convinced that it's confusing, or that there's a
| better alternative--but I appreciate your critique.
|
| Do you not think if someone can remember those four
| words, they're less likely to get it wrong?
|
| If you could contribute some better suggestions we could
| consider them!
| lintfordpickle wrote:
| 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?
| withinboredom wrote:
| I think they just reinvented 2-phase commit? I'm not sure
| either tbh.
| layer8 wrote:
| 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.
| withinboredom wrote:
| 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 wrote:
| 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.
| jorangreef wrote:
| 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.)
| mecsred wrote:
| If you read first and write last isnt that the opposite of
| committing and then reading to see what is comitted?
| layer8 wrote:
| Not sure why this was downvoted, the comment is completely
| right.
| tclancy wrote:
| I was hoping this was going to be advice for being a good citizen
| of the 'net, but this week seems to be Brought to You by Tiger
| Beetle, so here we are.
| aaroninsf wrote:
| One of the real pleasures of HN is that it provides for a
| clockwork-like enthusiastic rediscovery and re-articulation of
| basic computer science and systems concepts.
|
| It's almost enough to make me believe in the independent
| existence of Platonic truths. _Almost_.
| jorangreef wrote:
| Of course, there's nothing new except shining a spotlight (and
| coining the rule!).
___________________________________________________________________
(page generated 2025-11-11 23:02 UTC)