Diagrams

Bob, Alice and Carol are editing the same data item. When they try to send updates to the server, 8 RAYS cloud enforces the order that only changing last saved block state is actually allowed, so only one update is accepted and the rest get the merge request.

Here is the multimerge cycle sample; the "par" fragments here are special meaning: interactions inside the par gragment are executed in parallel, buth the sequence show their respectable order in time.

sequenceDiagram
    actor Alice
    actor Bob
    actor Carol
    participant Server
    Note over Server, Alice: initial data: Hello world
    par conflicting update 1
        Alice ->>+Server: data: Hello, world!
        Server -->>- Alice: accepted
        Bob ->>+ Server: data: Hello, cruel world
        Server -->>- Bob: merge request
        Carol ->>+ Server: data: Bye, world
        Server -->>- Carol: merge request
    end
    note left of Server: now "Hello, world!"

   par conflicting update 2
        Bob->>+Server: data: Hello, cruel world!
        Server -->>- Bob: accepted
        Carol->>+ Server: data: Bye, world!
        Server -->>- Carol: merge request
        Server --) Alice: update data
    end
    note left of Server: now Hello, cruel world!

   par update 3
        Carol->>+ Server: data: Bye, cruel world!
        Server -->>- Carol: accepted
        Server --) Alice: update data
        Server --) Bob: update data
    end
    note left of Server: now Bye, cruel world!
    Note over Server, Alice: synchronized data: Bye, cruel world!

Note that the update data push from the server is send asynchronously and in the case the party got "merge required" answer the rendundant notification could be trashed by the server, this is a RC based issue, so each "merge required" and "update data" has identification data to avoid repeating updates/megres.