Writing on distributed timestamps
- 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.
- 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.
- 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.
- 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.
- 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.
- Raft, in pictures: elections, quorum, and tsoracle's high-water mark
How Raft elects a leader, replicates entries by quorum, and why tsoracle's high-water mark is just another entry on the same log. With animated diagrams you can play through.
- Paxos, in pictures: ballots, promises, and the safety rule that makes it all work
How classic Paxos decides a single value, why dueling proposers livelock, how Multi-Paxos rescues throughput, and why tsoracle ships an omnipaxos driver next to the openraft one. With animated diagrams you can play through.