Craig Rodrigues Software Engineer in Silicon Valley
I was inspired to start this study group after taking Chiradip Mandal's course:
Data Algorithms
Mastering this topic requires constant study and review of:
We choose presentations that:
We are a study group: we learn together from papers, systems, and implementations.
We also act as a tech evaluation and critique group:
Debit − Account A $100 → $99 → Credit + Account B $50 → $51
Last session: debit/credit as a first-class primitive.
Slides: Presentations index
Main takeaways from Part 1:
From the TigerBeetle Architecture — Problem Statement:
TigerBeetle is a database for workloads that:
A deeper take on consensus through the lens of durability
Availability is a function of durability — and consensus is that function.
The talk reframes how we think about safety:
fsync
From the pre-work (slide 7):
Viewstamped Replication (1988) — Oki & Liskov Original primary-copy method for highly available distributed systems
Viewstamped Replication Revisited (2012) — Liskov & Cowling Same Oki protocol in spirit; clearer write-up + improved view-change subprotocol
TigerBeetle implements this VSR lineage (the revisited presentation).
A viewstamp is still a real identifier: view + op
From Oki & Liskov (original paper):
viewId
timestamp
viewstamp { viewId, timestamp }
<groupId, viewstamp>
Same protocol spirit; the write-up drops heavier 1988 module framing:
Even with f = 2 faulty nodes, a majority quorum of f + 1 = 3 can still make progress.
Core idea (VSR revisited): a replicated state machine with a single primary
From ARCHITECTURE.md + vsr.md:
prepare_ok
vsr.md
From Protocol: Normal — request → prepare → prepare_ok → reply
On each replica’s local disk, in that replica’s data file — not “in the network.”
From Durability and the Art of Consensus (~28:18):
When the primary fails, VSR already knows almost certainly who is next (Joran ~28:18):
primary(v) = v mod N\mathrm{primary}(v) \;=\; v \bmod N primary(v)=vmodN
Other VSR ideas Joran highlights:
Paper talk walkthrough (~18:07)
prepare
commit
exit_view
Same rule as before — everyone can compute the next primary locally:
TigerBeetle follows VSR (revisited) ideas but uses different command names (vsr.md):
join_view
view
get_view
view-change
view_change
Backups, when the primary goes quiet (vsr.md).
Replicas that have entered the next view’s change.
Only the new primary.
normal
TigerBeetle default: N = 6, view-change quorum 4. Primary R0 fails → new primary R1.
Highlighted R1–R4 = view-change quorum of 4. R5 can be live but is not required for that minimum.
get_headers
get_prepare
TigerBeetle doesn’t use one “majority” for everything (vsr.md — Quorums):
Different decisions → different thresholds.
This is the idea behind Protocol-Aware Recovery (FAST ’18).
Defaults from vsr.md — pick a cluster size (N), then read down the column:
Example (N = 6) (recommended): commit with 3, change views with 4.
You can commit more easily (only 3) than you can change leaders (need 4). That’s intentional.
Classic VSR/Paxos: (N = 2f + 1), one majority (f + 1) for everything.
TigerBeetle uses flexible quorums (Flexible Paxos):
In the protocol (vsr.md):
This table is about how many must participate — not a simple “how many can fail” chart.
https://sim.tigerbeetle.com/
Thank you:
These slides were prepared with the help of Grok AI.