In thinking about data consistency in the context of your applications, it may be useful to draw an analogy to the transaction isolation level for a multiuser database. A multiuser database must run with the serializable isolation level to assure that it provides results equivalent to a single-user database that users queue up to use. Only a system where all transactions are serializable is fully auditable. Nonserializable results cannot be assured of being reproducible.
Yet, all mainstream database products, including Microsoft® SQL Server™, operate by default with a transaction isolation level lower than serializable, typically read committed. SQL Server certainly allows the isolation level to be set to serializable, but the cost of doing so can be decreased concurrency due to share locks requiring to be held for a longer duration. Most database administrators choose (perhaps implicitly) to give up the assurance of serializability for the sake of concurrency (that is, performance). Either they know that their applications are not exposed to nonserializable states (because they never reread data in transactions), or they make a pragmatic decision that they can tolerate any such nonserializable results. Some database products opt for even lower isolation, read uncommitted (or “dirty read”), to obtain even higher concurrency.
This is very analogous to the decisions of data consistency in replication. For example, suppose any participating site can take an order from a customer, but doing so is based on first reading the customer’s credit rating, which each does from its local copy of the database. Unless the value for the credit rating is assured to be immediately consistent at all participating nodes, the act of taking the order may not be reproducible. The order may be rejected at one site but allowed at another, based on different values at a given moment for the credit rating. Even though taking the order does not modify the credit rating, the value for the credit rating still affects the behavior of the transaction.
However, there are a very large number of applications that do not require immediate transactional consistency. Many applications are naturally partitioned. For example, a sales force has strict territories, and two different sales representatives will never work for the same customer. Applications often have a natural geographic partitioning. For example, a customer may be allowed to do business in any branch office, but they only can be at one place at one time. The knowledge of such natural partitioning can be used in applications to achieve a higher degree of autonomy, without necessarily giving up anything in terms of transactional consistency. However, the burden here is largely on the application design. The database management system may provide constraints, rules, and views to help enforce partitioning, but the developer must nonetheless design for it.