This is a continuation of a discussion on Consensus algorithms as it appears here. Bayou, differs from both Paxos and Raft in its support for weakly consistent storage system over an environment with less than ideal network connectivity. Users can read and write any accessible replica. It has focused on supporting application specific mechanisms to detect and resolve the update conflicts. It includes novel methods for conflict detection called dependency checks and per-write conflict resolution based on the client provided merge procedures. It enables the rollback of previously executed writes and redo them according to a global serialization order. Bayou also permits clients to observe the results of all writes received by a server, including tentative writes whose conflicts have not been ultimately resolved.

The Bayou storage system provides an infrastructure for collaborative applications that manages the conflicts introduced by concurrent activity while relying only on the weak connectivity available for mobile computing. Bayou emphasizes supporting application specific conflict detection and resolution. The applications are expected to specify the notion of a conflict along with its policy for resolving conflicts. The system implements the mechanism for reliably detecting conflicts.

The system includes two mechanisms for automatic conflict detection and resolution that are intended to support arbitrary applications: dependency checks and merge procedures. These mechanisms permit clients to indicate for every write whether there is a conflict and the steps to resolve it. Each write operation includes a dependency check consisting of an application specified query and its expected result. A conflict is detected if the query, when run at a server against its current copy of the data, does not return the expected result. The dependency check is a precondition for performing the update that is included in the write operation.

An example of such a write can be described in terms of a meeting room scheduling application.  This write attempts to reserve an hour long time slot. The dependency check can be expressed in a SQL query that returns information about any previously reserved meetings that overlap with this time slot. The expected result is an empty set. The dependency check itself can be implemented with version vectors and timestamps as is conventional in distributed systems but it can also go beyond to resolve Read-Write conflicts where each write explicitly specifies the expected values of any data items on which the update depends, including data items that have been read but are not being updated. This is similar to the optimistic style concurrency control used in some databases. Dependency queries can read any data in the server’s replica, dependency checks can enforce arbitrary, multi-item integrity constraints on the data

Once a conflict is detected, a merge procedure is run by the Bayou server to resolve the conflict. It is responsible for resolving any conflicts detected by its dependency check and for producing a revised update to apply.  The end-to-end process of detecting a conflict, running a merge procedure, and applying a revised update, is performed atomically at each server as part of executing the write. Separating the dependency check from the merge procedure allows the servers to avoid running the merge procedure when the checks do not result in a conflict. In the event of an unresolved conflict by way of automatic resolution, the merge procedure still completes but with enough logging for a proper resolution by way of intervention later.

Reference: https://medium.com/paxos-algorithm/paxos-algorithm-71b76aaeb6b