---

Introduction

Imagine you're using an online banking application.

You transfer $10,000 from your Savings Account to your Checking Account.

Immediately after the transfer, you check your balance.

Should you see:

• ✅ Updated Balance ($40,000)
• ❌ Old Balance ($50,000)

Obviously, you expect the latest value.

Now imagine Instagram.

You upload a profile picture.

Your friend in another country still sees the old picture for 10 seconds.

Is that acceptable?

Yes.

These two applications have different Consistency Requirements.

Understanding consistency models is one of the most important skills for designing distributed systems.

---

Learning Objectives

After completing this article, you'll understand:

• What is Consistency?
• Why Consistency Models?
• Strong Consistency
• Eventual Consistency
• Causal Consistency
• Session Consistency
• Read-Your-Writes
• Monotonic Reads
• Monotonic Writes
• Quorum Consistency
• CAP Relationship
• Spring Boot Architecture
• Real-world Examples
• Best Practices

---

What is Consistency?

Consistency defines when all users observe the same value after data changes.

Example

User updates

Product Price

$100

↓

$120

Question

When should every user see $120?

The answer depends on the selected consistency model.

---

Single Database

flowchart TD
    USER[User]

    APP[Spring Boot]

    DB[(Database)]

    USER --> APP
    APP --> DB

Single-node databases naturally provide strong consistency.

---

Distributed Database

flowchart TD
    USER[Users]

    APP[Spring Boot]

    DB1[(Replica 1)]

    DB2[(Replica 2)]

    DB3[(Replica 3)]

    USER --> APP

    APP --> DB1
    APP --> DB2
    APP --> DB3

Multiple replicas introduce consistency challenges.

---

Why Consistency Models?

Imagine this situation.

Replica A

↓

Updated

Replica B

↓

Old Value

Which value should users receive?

Different systems answer this question differently.

---

Types of Consistency

flowchart TD
    ROOT[Consistency Models]

    STRONG[Strong]

    EVENTUAL[Eventual]

    CAUSAL[Causal]

    SESSION[Session]

    QUORUM[Quorum]

    ROOT --> STRONG
    ROOT --> EVENTUAL
    ROOT --> CAUSAL
    ROOT --> SESSION
    ROOT --> QUORUM

---

Strong Consistency

Every read returns the latest committed value.

sequenceDiagram
    participant Client
    participant Primary
    participant Replica

    Client->>Primary: Update Price
    Primary->>Replica: Replicate
    Replica-->>Primary: ACK
    Primary-->>Client: Success

Only after replication completes does the client receive success.

---

Strong Consistency Example

Bank Transfer

Transfer

↓

Commit

↓

Updated Balance Visible

No user ever sees stale data.

---

Advantages

• Latest data
• No stale reads
• Predictable behavior

---

Disadvantages

• Higher latency
• Lower availability
• More coordination

---

Eventual Consistency

Updates propagate asynchronously.

Eventually,

all replicas become identical.

sequenceDiagram
    participant Client
    participant Primary
    participant Replica

    Client->>Primary: Update Address
    Primary-->>Client: Success

    Note over Replica: Still Old Value

    Primary->>Replica: Replicate

    Replica-->>Primary: Updated

---

Eventual Consistency Timeline

Write

↓

Replica A Updated

↓

5 Seconds

↓

Replica B Updated

↓

Eventually Same Data

---

Where Eventual Consistency Works

Suitable for

• Social Media
• Product Reviews
• Recommendations
• Analytics
• News Feeds

Temporary stale data is acceptable.

---

Causal Consistency

Operations that are causally related are observed in the same order.

Example

Alice posts

Hello Everyone

Then comments

Welcome!

Users should never see the comment before the original post.

---

Causal Consistency Diagram

flowchart LR
    POST[Create Post]

    COMMENT[Create Comment]

    VIEW[Users Read]

    POST --> COMMENT
    COMMENT --> VIEW

---

Session Consistency

A user should always observe their own updates during a session.

Example

User updates profile picture.

Immediately refreshes the page.

The same user should always see the new picture.

---

Session Consistency Flow

flowchart TD
    USER[Same User]

    WRITE[Update Profile]

    READ[Read Profile]

    USER --> WRITE
    WRITE --> READ

---

Read-Your-Writes Consistency

Once a user performs a write,

future reads should return that update.

sequenceDiagram
    participant User
    participant Database

    User->>Database: Update Email
    Database-->>User: Success

    User->>Database: Read Email
    Database-->>User: Updated Email

Very common in SaaS applications.

---

Monotonic Reads

Once a user observes version 5,

they should never see version 4 again.

Version 4

↓

Version 5

↓

Version 6

Never

Version 6

↓

Version 5

---

Monotonic Reads Diagram

flowchart LR
    V1[Version 1]

    V2[Version 2]

    V3[Version 3]

    V1 --> V2
    V2 --> V3

Versions always move forward.

---

Monotonic Writes

Writes from one client are applied in the order they were issued.

flowchart TD
    W1[Write 1]

    W2[Write 2]

    W3[Write 3]

    W1 --> W2
    W2 --> W3

Order is preserved.

---

Quorum Consistency

Instead of contacting every replica,

the database waits for a majority.

Formula

R + W > N

Where

• N = Total Replicas
• R = Read Quorum
• W = Write Quorum

---

Quorum Diagram

flowchart TD
    CLIENT[Client]

    N1[(Replica 1)]

    N2[(Replica 2)]

    N3[(Replica 3)]

    CLIENT --> N1
    CLIENT --> N2
    CLIENT --> N3

Majority determines success.

---

CAP and Consistency

flowchart TD
    CAP[CAP Theorem]

    C[Consistency]

    A[Availability]

    P[Partition Tolerance]

    CAP --> C
    CAP --> A
    CAP --> P

Consistency models define how applications behave when balancing CAP trade-offs.

---

Spring Boot Architecture

flowchart TD
    CLIENT[React]

    API[Spring Boot]

    PRIMARY[(Primary)]

    REPLICA1[(Replica 1)]

    REPLICA2[(Replica 2)]

    CLIENT --> API

    API --> PRIMARY
    PRIMARY --> REPLICA1
    PRIMARY --> REPLICA2

Applications can route reads to the primary for strong consistency or to replicas for better scalability.

---

Banking Example

Requires

• Strong Consistency
• Read-Your-Writes
• Monotonic Reads

Customers must always see accurate balances.

---

Amazon Example

Strong Consistency

• Payments
• Orders
• Inventory Reservation

Eventual Consistency

• Reviews
• Recommendations
• Product Rankings

---

Netflix Example

Strong Consistency

• Subscription Status

Eventual Consistency

• Recommendations
• Trending Lists
• Continue Watching

---

Uber Example

Strong Consistency

• Ride Payment
• Driver Assignment

Eventual Consistency

• Driver Ratings
• Trip Analytics
• Promotions

---

Google Docs Example

Google Docs combines strong consistency for document editing with operational transformation techniques to keep multiple users synchronized.

---

Database Comparison

Database	Default Consistency
PostgreSQL	Strong
Oracle	Strong
MySQL InnoDB	Strong
MongoDB	Configurable
Cassandra	Eventual / Tunable
DynamoDB	Eventual (Strong Optional)
CockroachDB	Strong
Redis	Strong (Single Primary)

---

Comparison

Model	Latest Data	Performance	Typical Use Case
Strong	✅ Yes	Medium	Banking
Eventual	❌ Not Always	Excellent	Social Media
Causal	Related Operations	High	Messaging
Session	Same User	High	SaaS
Quorum	Majority	High	Cassandra

---

Advantages of Strong Consistency

• Predictable
• Financial Safety
• Easy to Reason About

---

Advantages of Eventual Consistency

• High Availability
• Better Scalability
• Lower Latency
• Better Geographic Distribution

---

Monitoring

Monitor

• Replication Lag
• Replica Health
• Read Latency
• Write Latency
• Consistency Errors
• Failed Replication
• Network Latency
• Conflict Resolution

Tools

• Datadog
• Grafana
• Prometheus
• CloudWatch
• OpenTelemetry

---

Common Mistakes

❌ Using eventual consistency for banking transactions

❌ Expecting immediate updates from replicas

❌ Ignoring replication lag

❌ No conflict resolution strategy

❌ Reading stale data after critical writes

---

Best Practices

• Use Strong Consistency for financial systems.
• Use Eventual Consistency for large-scale content platforms.
• Prefer Read-Your-Writes for user profile updates.
• Monitor replication lag continuously.
• Use quorum reads and writes when supported.
• Clearly document consistency guarantees for every API.

---

Common Interview Questions

What is a Consistency Model?

A consistency model defines when updates made to distributed data become visible to different clients and replicas.

---

What is Strong Consistency?

Every read returns the latest committed value immediately after a successful write.

---

What is Eventual Consistency?

All replicas eventually converge to the same value, but temporary stale reads are possible.

---

What is Read-Your-Writes?

A user always sees their own successful updates in subsequent reads.

---

When should Strong Consistency be used?

Strong consistency is ideal for banking, payment processing, inventory reservation, and other business-critical transactional systems.

---

Summary

Consistency Models define how distributed systems expose updated data to users. Choosing the correct model is a business decision that balances correctness, performance, availability, and user experience.

In this article, we covered:

• Consistency fundamentals
• Strong Consistency
• Eventual Consistency
• Causal Consistency
• Session Consistency
• Read-Your-Writes
• Monotonic Reads
• Monotonic Writes
• Quorum Consistency
• CAP relationship
• Spring Boot architecture
• Banking, Amazon, Netflix, Uber, and Google examples
• Monitoring
• Best practices

Understanding these models enables architects to design systems that provide the right level of consistency for each business capability, rather than applying a single approach to every workload.

---