With the aim of gaining in lower latency, allowing more concurrency and doing less work (hopefully), the idea of deferring the work that may not be needed to later stages is drawing the attention of systems developers not only for programming languages but also for DBMSs and file systems. However, the decision to introduce this laziness should take into account its drawbacks and system properties. In this OP we try to produce a “recipe” to help systems designers in this respect and we focus specifically in Eventual consistency multi-master replication.
We notice that this mechanism will ensure eventual consistency (correctness and termination will derive from the chosen algorithm proofs of these properties), even if some nodes might apply changes later than others. But there are also lazy mechanisms, consider:
The idea is to delay agreement work and only do it when a system policy requires it, one example could be when reads are performed on an item (in replica masters). Another policy could estimate a time in which reading old versioned items (in replica masters) is not considered to be harmful. In both cases we can also run N1 in batch mode (performing agreement in larger sets) to be more efficient.
The bet is that frequency(L2) << frequency(ui). The likeliness of this bet to hold depends on how well the policy fits the system, this might depend on the workload (e.g #reads vs #writes) or harmfulness of reading old version or more system probabilities (e.g. balancing updates between replicas).
Benefit of using lazy vs naive would be in terms of time that the system gains to enhance other properties like latency, bandwidth, concurrency, etc. So benefit = time(N1+N2)*(freq(updates)/freq(L2)-1)+time(L1) * freq(updates). And the cost will be to decrease the probability of having consistency between replicas during a period of time at a rate inversely proportional to benefit.