08 - CAP Theorem and Consistency

CAP Theorem and Consistency

Mental model

CAP applies to a distributed data system when a network partition occurs. You cannot simultaneously guarantee both strong consistency and availability across the partition.

CAP

C — Consistency

Every successful read sees the latest successful write (linearizable/strong consistency).

A — Availability

Every request to a non-failing node receives a response, without guaranteeing that it contains the latest data.

P — Partition Tolerance

The system continues operating despite communication failures between nodes.

flowchart TD
    Client --> A["Node A"]
    Client --> B["Node B"]

    A <-->|"Network"| B

    P["Network Partition"] -.-> A
    P -.-> B

    A --> D1[("Replica A")]
    B --> D2[("Replica B")]

The common interview mistake

CAP is not simply “pick any two of C, A and P.”

In a distributed system, partitions are a reality you generally must tolerate. During a partition, the important trade-off is Consistency vs Availability.

What Happens During a Partition?

Imagine inventory:

Node A: stock = 1
Node B: stock = 1
 
Network partition
 
Customer A → Node A → buy item ✓
Customer B → Node B → buy item ✓

Both sides remain available, but the system may temporarily disagree.

If we instead refuse one side’s write:

Node A → buy item ✓
Node B → reject request

we preserve stronger consistency at the expense of availability.

Strong vs Eventual Consistency

Strong Consistency

After a successful write:

WRITE stock = 0
       ↓
READ
       ↓
0

The reader sees the latest committed value.

Eventual Consistency

WRITE stock = 0
       ↓
Replica A = 0
Replica B = 1
       ↓
replication
       ↓
Replica B = 0

There can be a temporary window where replicas disagree.

Remember

Strong consistency = correct-now view.

Eventual consistency = replicas converge later.

E-Commerce Examples

Product Catalog

A product description changing from:

"Black T-Shirt"

to:

"Premium Black T-Shirt"

can often tolerate eventual consistency.

A user may briefly see the old description.

Inventory

Inventory is more sensitive.

Selling the last item twice is a business correctness problem.

Therefore inventory updates usually need a stronger consistency mechanism at the authoritative inventory boundary, such as:

• transactional DB update
• locking
• optimistic concurrency
• atomic conditional update

Important

“Eventual consistency” does not mean “don’t care about correctness.” It means we choose where temporary inconsistency is acceptable.

CAP vs ACID

These are different concepts.

ACID	CAP
Transaction properties	Distributed-system trade-off
Usually discussed at DB transaction level	Distributed data/system level
Atomicity, Consistency, Isolation, Durability	Consistency, Availability, Partition tolerance
Local transaction can provide ACID	Network partition creates distributed trade-off

The word Consistency means different things in these two contexts, so don’t treat them as synonyms.

PACELC

A useful extension for interviews:

PACELC

If there is a Partition, choose between Availability and Consistency.

Else, even without a partition, distributed systems often trade off Latency and Consistency.

You don’t need to implement PACELC in this project, but understanding it helps explain why distributed systems make consistency/latency trade-offs.

Interview Questions

Is PostgreSQL CAP = CA?

Be careful. CAP classification depends on the distributed deployment and failure model. Don’t casually label every relational database “CA.” A single-node database doesn’t face the same distributed partition scenario as a replicated cluster.

Is eventual consistency bad?

No. It is a deliberate trade-off. It is appropriate where temporary stale data is acceptable and scalability/availability matter.

Where would you accept eventual consistency?

Examples:

• product catalog propagation
• search indexes
• recommendation data
• analytics
• notification state

Where stronger consistency matters:

• account balance
• inventory reservation
• payment state transitions

Project Decision

We’ll use strong consistency inside a service’s authoritative database transaction where business correctness requires it, while accepting eventual consistency between services where appropriate.

That gives us a realistic hybrid model:

Within service
      ↓
Strong/local consistency
 
Between services
      ↓
Events + eventual consistency

Next

CQRS