DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Why Database Migrations Take Months and How to Speed Them Up
  • Unmasking Entity-Based Data Masking: Best Practices 2025
  • How Trustworthy Is Big Data?
  • Fixing Common Oracle Database Problems

Trending

  • How to Convert XLS to XLSX in Java
  • Cosmos DB Disaster Recovery: Multi-Region Write Pitfalls and How to Evade Them
  • How Trustworthy Is Big Data?
  • Infrastructure as Code (IaC) Beyond the Basics
  1. DZone
  2. Data Engineering
  3. Databases
  4. Consistency in Databases

Consistency in Databases

How will you know if a database is strong or eventual consistent?

By 
Navin Prakash Chanchal, PMP(R) user avatar
Navin Prakash Chanchal, PMP(R)
·
Updated Jun. 15, 18 · Analysis
Likes (11)
Comment
Save
Tweet
Share
19.8K Views

Join the DZone community and get the full member experience.

Join For Free

How will you know if a database is strong or eventual consistent?

The Rules

R + W > N

Ensures strong consistency. Read will always reflect the most recent write.

R=W= [Local_] QUORUM — Strong Consistency.

W + R <= N — Eventual Consistency.

W=1 — Good for fire-and-forget writes: logs, traces, metrics, page views, etc.

Definitions:

N= Replication Factor (number of replicas)

R= Number of Replicas read from (before the response is returned)

W= Number of replicas written to (before the write is considered a success)

QUORUM = (N/2 + 1) replicas read from before the response is a Return, and the same number of replicas written to before the write is considered a Success.

E.g. Suppose N = 2

Write one Read one = Weak

Write one Read All = Strong

Write All Read one = Strong

Write Quorum Read Quorum = Strong

E.g. Consistency Level in Cassandra

Consistency Level Write Read Consistency
Any 1 replica (including HH) - Weak
ONE 1 replica 1 replica Strong if N < 2, Else Weak as per R + W > N rule
TWO 2 replica 2 replica Strong if N < 4, Else Weak as per R + W > N rule
THREE 3 replica 3 replica Strong if N < 6, Else Weak as per R + W > N rule
QUORUM N/2 + 1 N/2 + 1 Strong
LOCAL_QUORUM
(to avoid latency issues
(dc_replicas)/2 + 1 (local Datacentre) (dc_replicas)/2 + 1 (local Datacentre) Strong
EACH_QUORUM
(useful in backup scenarios)
(dc_replicas)/2 + 1 (each Datacentre) (dc_replicas)/2 + 1 (each Datacentre) Strong
ALL N N

Strong


Consistency in MongoDB:

Below are write and read concerns in MongoDB.

Write Concern levels Description
0 Requests no acknowledgement of the write operation
1 Requests acknowledgement from the standalone mongod or the primary in a replica set.
number >1 valid only for replica sets to request acknowledgement from specified number of members, including the primary.
majority

Requests acknowledgement from the majority of voting nodes, including the primary.

Read Concern Levels Description
local reads against primary

reads against secondaries if the reads are associated with causally consistent sessions.
available reads against secondaries if the reads are not associated with causally consistent sessions.

unavailable for use with causally consistent sessions.
majority returns data that has been acknowledged by a majority of the replica set members
linearizable

returns data that reflects all successful majority-acknowledged writes that completed prior to the start of the read operation


linearizable is unavailable for use with causally consistent sessions.


Causal Consistency Session

Causal relationship means that an operation logically depends on a preceding operation. MongoDB executes causal operations in an order that respects their causal relationships, and clients observe results that are consistent with the causal relationships.

Consistency Levels and Guarantees

Consistency Level Guarantees
Strong Reads are guaranteed to return the most recent write
Bounded Staleness Consistent Prefix. Reads lag behind writes by at most k prefixes or t interval
Session Consistent Prefix. Monotonic reads, monotonic writes, read-your-writes, write-follows-reads
Consistent Prefix Updates returned are some prefix of all the updates, with no gaps
Eventual

Out of order reads

Causal Consistency Guarantees Description
Read your writes Read operations reflect the results of write operations that precede them.
Monotonic reads Read operation do not return results that corresponds to an earlier state of the data than a preceding read operation.
Monotonic writes Write operations that must precede other writes are executed before those other writes.
Writes follow reads

Write operations that must occur after read operations are executed after those read operations.

Image title

If we see the consistency in MongoDB implementation, it will be something like below:

Consideration Write Concern Read Concern Consistency
Real Time Order majority linearizable Strong
Read Your Own Writes causally consistent session causally consistent session Weak
Read Your Own Writes majority majority / linearizable

Strong


CAP Theorem

Image title

PACELC Theorem

If there is Partition:

Then system trade-offs between Availability and Consistency

Else system trade-offs between Latency and Consistency

Image title


Database can be configured in one of below way as mentioned as per PACELC theorem :

DDBS ( one of these --> )  P+A P+C E+L E+C
DynamoDB Yes Yes
Cassandra Yes Yes
Cosmos DB Yes Yes
Riak Yes Yes
VoltDB/H-Store Yes Yes
Megastore Yes Yes
BigTable/HBase Yes Yes
MongoDB Yes Yes
PNUTS Yes Yes
Hazelcast IMDG Yes Yes

Yes

ACID

Atomic: Atomic means “all or nothing;” that is, when a statement is executed, every update within the transaction must succeed in order to be called successful. There is no partial failure where one update was successful and another related update failed. The common example here is with monetary transfers at an ATM: the transfer requires subtracting money from one account and adding it to another account. This operation cannot be subdivided; they must both succeed.

Consistent:
Consistent means that data moves from one correct state to another correct state, with no possibility that readers could view different values that don’t make sense together. For example, if a transaction attempts to delete a Customer and her Order history, it cannot leave Order rows that reference the deleted customer’s primary key; this is an inconsistent state that would cause errors if someone tried to read those Order records.

Isolated:
Isolated means that transactions executing concurrently will not become entangled with each other; they each execute in their own space. That is, if two different transactions attempt to modify the same data at the same time, then one of them will have to wait for the other to complete.

Durable:
Once a transaction has succeeded, the changes will not be lost. This doesn’t imply another transaction won’t later modify the same data; it just means that writers can be confident that the changes are available for the next transaction to work with as necessary.

Image title

BASE

How do the vast data systems of the world such as Google’s BigTable and Amazon’s Dynamo and Facebook’s Cassandra deal with a loss of consistency and still maintain system reliability? The answer is BASE (Basically Available, Soft state, Eventual consistency). The BASE system gives up on the consistency of a distributed system.

Image title


Tunable Consistency is a term used in Cassandra for tuning the consistency levels.

Based on System requirement, it should be tuned accordingly for consistency.


Next Steps :

You may further explore on it, here are some related links :

https://www.mongodb.com/mongodb-architecture

http://cassandra.apache.org/doc/latest/architecture/dynamo.html#tunable-consistency

https://hbase.apache.org/acid-semantics.html

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/filesystem/introduction.html#Consistency



Database

Opinions expressed by DZone contributors are their own.

Related

  • Why Database Migrations Take Months and How to Speed Them Up
  • Unmasking Entity-Based Data Masking: Best Practices 2025
  • How Trustworthy Is Big Data?
  • Fixing Common Oracle Database Problems

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!