It requires a different primary key than an autoincrementing integer. One popular choice is to use a tuple of (peer_guid, incrementing integer). Or a randomly generated GUID, or a hash of the associated data.

Then each event is associated with zero or more "parent events".

- An event has 0 parents if it is the first change

- An event has 1 parent if it simply came after that event in sequence

- And if an event merges 2 or more branches in history, it says it comes after all of those events

You can also think about it like a set. If I know about events {A, B, C} and generate event D, then D happens-after {A, B, C}. (Written {A,B,C} -> D). But if A->B, then I only need to explicitly record that {B,C} -> D because the relationship is transitive. A -> B -> D implies A -> D.

And the moment you need to merge, unrepresentable states become possible.

There are techniques to make it less painful, but it will still be possible.

You mean, like attempting to merge contradictory states? You will need some resolution stategy then, but in general that would be application-specific, and sometimes it may not exist.

Okay... But we're now back to invalid states being possible. Tagging with time isn't enough.

It isn’t enough for what? What are you trying to do?

There may be a way to solve whatever problem you have, but without specifics it’s impossible to tell.