Understanding Consistency
What is consistency?
Consistency, states that data cannot be written that would violate the rules for valid data. If a certain action occurs that attempts to introduce inconsistent data, the entire action is rolled back and an error returned to the user, and there are many types for consistency like strong consistency and eventual consistency
What is Strong consistency?
Strong Consistency simply means the data will get passed on to all the replicas as soon as a written request comes to one of the replicas of the database to make all nodes across the world should contain the same value
And the only way to implement this behavior is by locking down the nodes when being updated like in a relational database.
for example, Imagine you go to the ATM and withdraw some money from your account then you take the money and check your account balance and see the withdrawal money deducted from your account successfully
in our case we see that :
- The Atm is blocked tell we get our money and the receipt
- The money is deducted immediately
What is Eventual consistency?
Eventual consistency makes sure that the data of each node of the database gets consistent by the time. Time is taken by the nodes of the database to get consistent may or may not be defined like in Non-relational databases.
for example, Imagine you go to a shop and order 2 products. The cashier takes your order, you pay and then you wait for the order to be ready
As you move to the next window waiting to pick up your order to be ready
in our case we see that :
- The cashier was available to take your order and gave you a receipt of your transaction
- You have a guarantee that you will eventually get your order, but you don’t know the exact time
Consistency in the database system
in database system consistency ensures that database state will be valid after any transaction happened, maintaining database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof.
Relational databases have ACID properties which intended to guarantee data validity despite errors, power failures, and other mishaps to ensure a strong consistency
NoSQL databases have BASE that rather than make ACID guarantees, the database trying to balance consistency and data availability. This is typically the case when nodes in a given database cluster act as primary managers of a part of the database, and other nodes hold read‐only replicas.
Consistency With CAP theorem
CAP is sometimes presented as Consistency, Availability, Partition tolerance pick 2 out of 3.
Unfortunately, putting it this way is misleading because network partitions are a kind of fault, so they aren’t something about which you have a choice: they will happen whether you like it or not.
At times when the network is working correctly, a system can provide both consistency and availability.
but if the network is not working correctly you should design your system to have a degree of Consistency ( strong, week, Eventually, etc ..) and your choice will affect the availability
Consistency in the distributed system
the distributed system usually has multi-node providing read and writes to ensure high availability and scalability but this may introduce some problems :
- Message asynchronous (asynchronous): The real network is not a reliable channel, there are message delays or loss
- node-fail-stop: The node continues to crash and will not recover
- node down recovery (: Node recovery after a period of time, the most common in distributed systems
- network partition: There is a problem with the network link, separating N nodes into multiple parts
so most of the distributed systems trying to ensure consistency eventually using ( 2pc, 3pc , sages, etc …)
Conclusion
At the end of this article, those are some resources for reading and getting more knowledge
