[otterley]

You can’t be certain that any given mutating operation you perform now won’t be relied upon for some future operation, unless the two operations are performed in entirely different domains of data. Even “not touching (by which I assume you mean mutating) the same data” isn’t enough. If I update A in thread 0 from 1 to 2, then I update B in thread 1 to the value of A+1, then the value of B could end up being 2 or 3, depending on whether the update of A reached thread 1.

[sreekanth850]

In distributed systems, dependencies flow forward, not backward. Causal dependency only exists when an operation actually references earlier state. If B = A+1, then yes, B is causally dependent on A and they must share an order. But that dependency is created by the application logic, not assumed globally in advance.

We shouldn’t impose a universal timeline just because some future operation might depend on some past one. Dependencies should be explicit and local: if two operations interact, they share a causal scope; if they don’t, they shouldn’t pay the cost of coordination.

[otterley]

> But that dependency is created by the application logic, not assumed globally in advance.

Not necessarily. If you allow users to perform arbitrary operations on the data, all bets are off.

> We shouldn’t impose a universal timeline just because some future operation might depend on some past one. Dependencies should be explicit and local: if two operations interact, they share a causal scope; if they don’t, they shouldn’t pay the cost of coordination.

Application developers can already avoid that cost by using separate databases for different data domains. That’s very explicit and effectuates intent rather nicely.