Consistency Models Explained: What Eventually Consistent Means for Your Inbox
If you act on what you read eight minutes ago, you're acting on a guess.
Here's a real one from my own company. A client thread got read at 10:50. A record and an invoice got built off that read at 10:58. The client's decline had landed at 11:01.
Nobody screwed up. The read was just old by the time the action ran.
10:50 READ thread says "go ahead"
|
| (8 minutes of the world moving on)
|
10:58 ACT record + invoice built from the 10:50 read
|
11:01 TRUTH ARRIVES decline lands in the thread
------------------------------------------------
what a re-read at 10:57 would have caught: nothing
what a re-read at 11:02 would have caught: everything
Look at the gap between READ and ACT. That gap is where every stale-read bug lives.
Distributed systems people have a whole vocabulary for this, and it's worth borrowing. The short version: eventual consistency means every copy of the data agrees, eventually, but not necessarily right now. Linearizable means you always see the latest write. Almost nothing in a real small-business stack is linearizable. Your email isn't. Your CRM isn't. Your phone assistant's transcript isn't. Kyle Kingsbury's map of consistency models lays out the whole family tree if you want the formal names, and honestly it reads better than most textbooks.
Here's the part that bugs me. Everybody builds automations that read once at the top of the job and then run four steps off that snapshot. Fetch thread, classify, build record, generate invoice, send. Feels clean. Feels efficient. And every step after the first is operating on a photograph of a moving thing.
I'm not the type to add ceremony for its own sake, but I changed one thing: the step that commits anything, the one that writes a record or sends money-shaped documents out, re-reads the source right before it fires. Not at the top. At the moment of commitment. If the thread changed, it stops and flags instead of finishing. Cheap. One extra call. It has caught things I would never have caught by being careful.
Same rule applies to humans, by the way. I read a thread, get pulled into the field for twenty minutes, come back and start typing a reply from memory. That's a stale read with a person in the loop. I gotta refresh first. The system doesn't care whether the stale copy was in a cache or in my head.
The fix isn't faster polling. Faster polling just shrinks the window, it doesn't close it. The fix is moving the read next to the write.
Read early to decide. Read again to commit.
Jesse