Yes I’ve read through TigerBeetle’s VSR design and their rationale for not using Raft.
VSR makes a lot of sense for their problem space: fixed schema, deterministic state machine,
and a very tight control over replication + execution order.
Ayder has a different set of constraints:
- append-only logs with streaming semantics
- dynamic topics / partitions
- external clients producing arbitrary payloads over HTTP
Raft here is a pragmatic choice: it’s well understood, easier to reason about for operators,
and fits the “easy to try, easy to operate” goal of the system.
That said, I think VSR is a great example of what’s possible when you fully own the problem
and can specialize aggressively. Definitely a project I’ve learned from.
Even some BIFs and NIFs (BIF are mostly just an built-in NIFs) can yield [1]
and choose to reschedule themselves later. But inside the C code it is voluntary, of course. An example of this can be seen when running hash functions [2].
Another interesting idea is that a NIF which may not reschedule themselves with yield, can still signal the scheduler that they are consuming so many "reductions" if they did some lengthy work. So if, say, they run for 10 msec, they might want to bump the reduction counter a bit: enif_consume_timeslice. Otherwise a tight recursive loop calling the same NIF could still effectively block the VM.
