'Cause I'm strong enough: Reasoning about consistency choices in distributed systems

Abstract

Large-scale distributed systems often rely on replicated databases that allow a programmer to request different data consistency guarantees for different operations, and thereby control their performance. Using such databases is far from trivial: requesting stronger consistency in too many places may hurt performance, and requesting it in too few places may violate correctness. To help programmers in this task, we propose the first proof rule for establishing that a particular choice of consistency guarantees for various operations on a replicated database is enough to ensure the preservation of a given data integrity invariant. Our rule is modular: it allows reasoning about the behaviour of every operation separately under some assumption on the behaviour of other operations. This leads to simple reasoning, which we have automated in an SMT-based tool. We present a nontrivial proof of soundness of our rule and illustrate its use on several examples.

Conflict-Free Replicated Data Types CRDTs

“…A number of other works have proposed techniques to verify the correctness of distributed systems that run under weak consistency, identifying when coordination is necessary [46,10,62,33,73,6]. Some of these works focused on systems that use CRDTs.…”

“…In runtime, depending on the operation parameters, the system runs an operation under weak or strong consistency. Some works [10,33,73] require the developer to specify the properties that the distributed system must maintain, and a specification of the operations in the system (that is often independent of the actual code of the system). As a result, they state which operations cannot execute concurrently.…”

Interactive checks for coordination avoidance

“…This is good news because checking if an object is invariant closed is more straightforward than checking if it is invariant confluent. Existing systems typically use an SMT solver like Z3 to check if an object is invariant closed [16,9,20]. If it is, then by Theorem 1, it is invariant confluent.…”

Ensuring referential integrity under causal consistency

“…The effector must have the same effect at every replica, and therefore may not depend on testing shared state. We assume an operation's preconditions are stable, i.e., evaluating the precondition to true does not change under any concurrent operation [6]. 1 We assume causal consistency, i.e., one operation's effector is delivered (to some replica) only after the effectors of operations that are visible to it.…”