Deterministic replay
Deterministic replay is what recovery leans on: the same input re-run yields the same output.
Also called: replayability
Deterministic replay - re-run the same input through the same computation and get the same output, which is the deterministic replay streaming engines rest their whole recovery story on. If the log is replayable and the computation is deterministic, a crash stops being an emergency: load the last checkpoint, replay the log from the recorded offset, arrive at the state you would have had anyway. Kreps's log essay made the first half canon; the second half is on you. Wall-clock timestamps, random numbers, iteration order over a hash map, a lookup table that changed underneath: each one makes a replay quietly diverge from the run it replaces.
So determinism is a discipline. Event time instead of processing time, seeded randomness or none, pinned reference data.
Do you need it? Yes, and it is the cheapest correctness property on this page: no coordinator, no protocol, just refusing nondeterminism. Ubik is built on it, replay from one atomic checkpoint, and a resume refuses to run if the already-consumed log or a lookup dimension changed since that checkpoint was taken. Recovery is boring, which was the goal.