tso
- When you need a TSO (and when you don't)
A timestamp oracle solves a narrow problem: total order across machines. When you actually need one, and when something weaker is the right call.
- How tsoracle's window allocator works
Inside tsoracle: the window allocator amortises one fsync into many IDs while keeping every issued timestamp strictly monotonic across crashes.
- Gapless sequences: GetSeq alongside GetTs
tsoracle now hands out two kinds of strictly-ordered integer: monotonic timestamps and gapless, dense sequences. What gaplessness costs, why GetSeq is non-idempotent, and when to reach for it.
- Why distributed systems need a timestamp oracle
A timestamp oracle hands out strictly increasing IDs that order events across a distributed system. Why cross-machine ordering is hard, and what a TSO solves.
- Wiring tsoracle into openraft
A timestamp oracle needs a replicated log under it. Inside tsoracle's ConsensusDriver trait, the openraft driver, and the envelope pattern for piggybacking on your service's existing raft.
- TSO vs UUIDv7
A timestamp oracle gives strict global monotonicity; UUIDv7 gives k-sortable IDs locally. When each is correct, and where UUIDv7 silently fails.