> the relations between events happening in a distributed system, is more fundamental than their absolute ordering
The important thing in most distributed systems is having an order. Having a single observer serialize events as it receives them is so much more tractable than trying to use absolute order. Using absolute order requires very precise time synchronization which is hard; using absolute order requires knowing when you have received all the reports of events that already happened which is hard. Determining a designated observer isn't typically easy, but having it determine the order it observes events is easy. If two events happen at a similar time it's typically not a big deal which one is considered first as long as all nodes will agree on the result --- let the designated observer just pick the first one it sees works pretty well. If your report takes an unexpectedly long time to make it to the designated observer, then it won't be first and you'll deal.
Much better than trying to figure out unknowable questions of relativity. :P
There is no such thing as a general order; if people accept this then the problem relaxes and we stop trying to design impossible things.
Nodes shouldn't be observers. End users should be the observers. The ordering of event only matters from the perspective of the "I'm adding this to my shopping cart and clicking the buy button and then it said I bought it" story being internally consistent. The observer here is the end user and the end user knows what happens-before relationships were.
Databases should flip this ordering inside out and let the observers (or proxies for them) report what they did in which order. And it just happens that protocols for doing this already exist: distributed tracing encodes these relations.
A meaningful global order doesn't exist and attempts to conjure one only conjure a meaningless one, or one that throws away a lot of turns trying to perfectly order everything from some arbitrary internal observer.
> "I'm adding this to my shopping cart and clicking the buy button and then it said I bought it"
If there's only one of the item to buy and two users wanted to buy it at the same time, it can only be shipped to one of them.
From each user's perspective, their add to cart (and maybe their click to buy) happened before the other user's, but alas, there is only one item available for immediate shipment.
Allowing customers to arbitrate a dispute over control of the item doesn't always go so well; see examples on Black Friday.
Even without a conflict over a mutually exclusive resource, it is valuable in many contexts for all users to share the order of observed events. That's difficult if user agents send events directly to all other agents and report observations to the user as soon as the remote reports arrive.
If A and B both report events and some users see A then B while others see B then A, there may be confusion and a poor user experience. Of course, for some things, relative ordering is unimportant.
> absolute order requires very precise time synchronization which is hard
Presumably relativity is the reason precise time synchronization (and thus absolute ordering) is hard.
That forms a basis for the difficulty. But then there's additional layers of difficulty in real networks where the path between nodes is often asymmetric, and you may also observe that elapsed time (A -> B -> A) is sometimes greater than elapsed time (A -> C -> B -> C -> A) or (A -> C -> B -> A) or (A -> B -> C -> A)
Doesn't each node just need to know its exact path (or latency of same) to the time source each is synchronizing from? The path from node to node doesn't matter because we're ordering log entries from the timestamp of the receiving node.
Imagine you take three atomic clocks, synchronize them, and move each within exactly 1 meter of one of those nodes, directly connected in an identical manner. Relativistic effects are constant. If there are elevation differences, you factor it once and done. The problem with this setup is not relativity. It is quantum uncertainty (and various interference sources, thermal radiation, etc).
How do you know the latency of the path if you haven't synchronized the clocks...
You might be able to control the latency on a LAN, but once you have servers in different locations, good luck. (GPS helps a lot, of course...)
There is this command called 'ping' that tells you that. But in my example, I included the network topology as a known, static factor.
> There is this command called 'ping' that tells you that.
Ping tells you the round trip latency. As I mentioned, asymmetric routing is common and very difficult to measure.
> But in my example, I included the network topology as a known, static factor.
Ok, so spherical cows.
yes, it can be easier to have a central serializer for events, but that certainly makes things problematic for fault tolerance and basically excludes large-scale solutions. using an agreed-upon post-hoc ordering based on timestamps is certainly another way, but really only if you're working in a paradigm that lets you impose it (like mvcc) or doesn't care (like crdt).
personally I find when you view events in a distributed system as a partial order, its more liberating than confusing. its not unusual to assume that there is some kind of canonical event ordering that we have to preserve, when its often just not semantically important. so its a useless constraint that can impose complexity and limit the solution space. the partial ordering exposes the real causal constraints.