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.