architect-handbook

Software Architect Handbook

View on GitHub

Strong consistency

Overview

All changes are atomic. If a transaction updates multiple data items, the transaction is not allowed to complete until either all of the changes have been made successfully, or if there’s a failure, they have all been undone.

In the team between a transaction starting and completing, other concurrent transactions may not be able to access any of the data that has been modified; they will be blocked.

If data is being replicated, a transaction that implements strong consistency is allowed to complete until every copy of each iteam that has changed has been updated successfully.

It aims to minimize the chance that an application instance might be presented with an inconsistent view of the data.

Disadvantages

The cost of implementing this model is the impact it has on the availability, performance, and scalability of the resulting solution.

Impact on distributed environments

In a distributed application, you should implement strong consistency only where it is absolutely necessary.

For example, if an application updates multiple items that are located within the same data store, the benefits may outweigh the disadvantages because data is likely to be locked only for a very short period.

An alternative approach for maintaining strong consistency across replicated data that is frequently implemented by highly scalable NoSQL databases is to use read and write quorums and versioning.