> Isn't this a core feature of distributed systems? How can you be "consistent" if there's a network failure between some writer and the stream? How can you tell a network failure from a network delay? How can you tell a network delay from any other delay?
The basic solution is: If you need consistency and there's too much network failure (or delay), you'll have to pause operations and wait until the network is fixed.
If there's only a bit of network failure (or delay), consistency stays possible using quorum protocols such as Paxos and Raft.
> how can you even talk about "up-to-date" data if the reader doesn't provide their "date" (ie, a logical timestamp)?
Implicit causality helps.
You're right that there may be no definite logical time, but it often doesn't matter.
When a program issues a read command, the logical timestamp is, implicitly, greater than the timestamp of all results previously received from the network that were inputs to produce the read command.
So the rest of the network "knows" something about the logical time of the read command. It's not an exact logical time, and if the timestamps aren't passed around, it might not even be an inequality. It's more like a logical property that relates dependent values.
If done right, that's enough to ensure strict consistency in observable results.
Unless the program issuing reads does wild things with value speculation. You may have heard how much things can go wrong with speculative execution...
This is covered by the CAP theorem. https://en.wikipedia.org/wiki/CAP_theorem
The basic solution is: If you need consistency and there's too much network failure (or delay), you'll have to pause operations and wait until the network is fixed.
If there's only a bit of network failure (or delay), consistency stays possible using quorum protocols such as Paxos and Raft.
> how can you even talk about "up-to-date" data if the reader doesn't provide their "date" (ie, a logical timestamp)?
Implicit causality helps.
You're right that there may be no definite logical time, but it often doesn't matter.
When a program issues a read command, the logical timestamp is, implicitly, greater than the timestamp of all results previously received from the network that were inputs to produce the read command.
So the rest of the network "knows" something about the logical time of the read command. It's not an exact logical time, and if the timestamps aren't passed around, it might not even be an inequality. It's more like a logical property that relates dependent values.
If done right, that's enough to ensure strict consistency in observable results.
Unless the program issuing reads does wild things with value speculation. You may have heard how much things can go wrong with speculative execution...