Consistent Prefix Reads In the book Designing Data-Intensive Applications, the author suggests that replication lag can lead to an anomaly were causality is violated. In the example that the author uses, the system is both replicated and partitioned. I was wonder if the violation of causality - what the author terms &quot;consistent prefix reads&quot; - is a problem in non-partitioned systems as well.
P.S. I want to expand on this. In a single leader replicated system, the single leader acts as a synchronization point. All follower replicas will see the writes in the correct order, so I do not see how a third-party observer would see the writes in the wrong order. I am starting to arrive at the conclusion that causality can be violated in a multi-leader replicate system because the lag between L2 and F1 can be larger than L1 and F1.
Yes, attaining consistent prefix reads is still a problem in replicated non-partitioned systems (or for reads within a single partition of a partitioned replicated system which gets the same treatment as a non-partitioned replicated system for this issue) IF replication is asynchronous or semi-synchronous.
A single client could read from follower1 and then make a subsequent read to follower2. If follower2 is lagging, the second read of data from that partition may reflect an older state of your data model than the first read of data served by follower1. So any business logic that requires the causality sequence could become erroneous.
Now, this leads to the next point: if you achieve the monotonic reads guarantee for the client, a concept usually discussed in the context of reading from a single partition or unpartitioned system, then you also get the consistent prefix reads guarantee under the single-partition assumption. The way to do this is to force the same clientID to read from the same replica, or only have a single replica (the leader), or force all the replication to be synchronous. If you have multiple partitions, on the other hand, achieving monotonic reads per partition still don't guarantee you consistent prefix reads, which is the point Martin makes in the book.
To correct what you said:

In a single leader replicated system, the single leader acts as a synchronization point.

No, the single leader is only a synchronization point for writes, but could be a synchronization point for both reads+writes if those reads are forced to go through the leader. When doing transactions involving both read/writes, you want to go through the leader. When doing reads where stale data is fine, you would want to make use of your replicas.

All follower replicas will see the writes in the correct order, so I do not see how a third-party observer would see the writes in the wrong order.

No, as per my example, even though replicas eventually see all writes in the correct order, the client can read from different replicas and see the writes out of order unless you constrain otherwise to achieve monotonic reads.

I am starting to arrive at the conclusion that causality can be violated in a multi-leader replicate system because the lag between L2 and F1 can be larger than L1 and F1.

Yes but also in a single-leader replicated system as I hope I have explained properly above.