DaemonOne problem.
One month.
All the way down.
A monthly dispatch that dissects one backend engineering problem down to the syscall. Written by practitioners. Read by those who've debugged it at 3 AM.
Reserve Issue One"The internet runs on backend engineering.
The writing about it does not."
You have been a senior engineer long enough to know that tutorials are not written for you. The blog posts that reach your feed are optimized for clicks, not comprehension. The conference talks summarize papers you already read. The newsletters aggregate what you already know.
What you actually want — what you have always wanted — is the analysis that lives in internal postmortems at Stripe, in the engineering docs at Cloudflare, in the runbooks at Fly.io that nobody publishes because it took six months to write and two production incidents to earn.
You want someone to sit with a problem long enough that they understand it the way a surgeon understands anatomy — not from diagrams, but from having their hands inside it.
In the spring of 2024, I spent four hours debugging a Raft implementation in production. Not a toy — a consensus layer carrying real write traffic. The cluster had elected a new leader after a network partition, and something in the commit pipeline had gone quietly wrong.
I opened every tab I could find. The Raft paper. The TiKV internals blog. The etcd source. I found explanations of what Raft does. I found nothing written at the level I needed — nothing that traced from the algorithm through the implementation to the specific failure mode I was holding.
The fix was three lines. The understanding took four hours and two primary sources and a read of the original Raft dissertation, not just the paper. Here is what that code looked like.
// raft/log.go — the line that cost us four hours
// commitIndex was advancing past matchIndex
// because we forgot: leader election resets matchIndex to 0,
// not to the last known committed entry.
func (r *Raft) maybeCommit() {
// BUG: matchIndex[r.id] never updated on election
// so quorum calculation silently excluded the leader itself.
for n := r.commitIndex + 1; n <= r.log.lastIndex(); n++ {
if r.log.term(n) != r.currentTerm {
continue // Raft §5.4.2 — only commit current term entries
}
quorum := 1 // counting self — but self was wrong
for _, peer := range r.peers {
if r.matchIndex[peer] >= n {
quorum++
}
}
if quorum > len(r.peers)/2 {
r.commitIndex = n
// entries committed but state machine diverged
// because matchIndex[leader] = 0 after election
}
}
}
// fix: r.matchIndex[r.id] = r.log.lastIndex() on election win
// three lines. four hours. one postmortem.
That experience is why this exists. Not to explain Raft to beginners. To write the document I needed that night — the one that assumes you have read the paper, have written the code, and still cannot find what you need.
One issue.
One topic. All the way down.
Each issue of Daemon is a monograph, not a newsletter. It is between 4,000 and 8,000 words. It has footnotes. It has original diagrams. It cites primary sources and tells you when it cannot find them. It is written the way a good internal postmortem is written, with the assumption that the reader is already a practitioner.
It arrives once a month. There is no daily digest, no sponsored content, no "quick takes." The constraint is the product.
Issue One ships in March 2026.
Reserve your copy. No payment. Just your email.
The Ghost in the Consensus:
What the Raft Paper Doesn't Tell You About Leader Election Under Partition
From the Raft dissertation's edge cases to the kernel scheduler interactions that cause split-brain in practice. Primary sources, original diagrams, and the three implementation bugs that every production Raft cluster has already hit — whether its operators know it yet or not.
This is the analysis I needed that night. It took three months to write correctly. It will take you an evening to read. The waitlist is the only path to Issue One.
engineers on the waitlist
As of February 2026