9 comments

[ 2.6 ms ] story [ 31.8 ms ] thread
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.

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?

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.
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.

Of course, there’s nothing new except shining a spotlight (and coining the rule!).
This was a lovely piece. I'm only surprised by paucity of interesting comments here. If Joran or anybody sees this late comment: I'd appreciate any other references to the approach. Surely it wasn't invented by TigerBeetle?
Hey thanks for the kind words, I am happy you liked the article. You are correct, we did not come up with the rule (but Joran did come up with the name) but drew from the rich history of transaction management systems.

A wonderful paper that I highly recommend is A Transaction Model from Jim Gray, that illustrates like no other than transactions are all about coordinating actions and when to externalize their results to a user. The mental model presented in this paper frequently informs my thinking when designing systems

https://jimgray.azurewebsites.net/papers/a%20transaction%20m...