Editing Consistency model (section)

== Types ==

Consistency models define rules for the apparent order and visibility of updates, and are on a [[linear continuum|continuum]] with tradeoffs.<ref name="Rules">{{cite web
| access-date = 2011-03-24
| author = Todd Lipcon
| date = 2014-10-25
| title = Design Patterns for Distributed Non-Relational Databases
| quote = A consistency model determines rules for visibility and apparent order of updates. Example: * Row X is replicated on nodes M and N * Client A writes row X to node N * Some period of time t elapses. * Client B reads row X from node M * Does client B see the write from client A? Consistency is a continuum with tradeoffs
| url = http://cloudera-todd.s3.amazonaws.com/nosql.pdf
| archive-date = 2014-11-03
| archive-url = https://web.archive.org/web/20141103164710/http://cloudera-todd.s3.amazonaws.com/nosql.pdf
| url-status = dead
}}</ref> There are two methods to define and categorize consistency models; issue and view.
; Issue: Issue method describes the restrictions that define how a process can issue operations.
; View: View method which defines the order of operations visible to processes.

For example, a consistency model can define that a process is not allowed to issue an operation until all previously issued operations are completed. Different consistency models enforce different conditions. One consistency model can be considered stronger than another if it requires all conditions of that model and more. In other words, a model with fewer constraints is considered a weaker consistency model.

These models define how the hardware needs to be laid out and at a high-level, how the programmer must code. The chosen model also affects how the compiler can re-order instructions. Generally, if control dependencies between instructions and if writes to same location are ordered, then the compiler can reorder as required. However, with the models described below, some may allow writes before loads to be reordered while some may not.