Data Consistency

Why consistency matters

Imagine a shared Google Doc where one teammate sees the old sentence while another sees the edited version. In distributed systems, that mismatch happens with data, not just text. A user's profile, inventory count, or bank balance may be stored on multiple machines for speed and reliability. The hard part is making those copies agree.

Data consistency asks: when data changes in one place, when and how do other copies reflect that change?

This matters because users make decisions based on what they read:

• If an online store says 1 item left, two buyers may both try to purchase it.
• If a payment app shows $500 on one server and $450 on another, the user may overspend.
• If a social app shows an old password hash on one node, login behavior becomes unpredictable.

In short, distributed systems trade simple truth for replicated truth.

Strong consistency: one truth, immediately

Think of strong consistency like a classroom vote where the teacher announces the official count before anyone can act on it. After a write completes, every later read returns the most recent value.

If Priya updates her shipping address from 12 Oak St to 88 Pine Ave, then any server read after the update must return 88 Pine Ave.

This is powerful for systems where mistakes are expensive:

• bank account balances
• stock trading orders
• seat reservations
• medical records

But strong consistency often costs:

• higher latency because replicas must coordinate
• lower availability during network issues
• more complex write paths

A simplified write flow might look like:

Client -> Leader Replica: write x=42
Leader -> Followers: replicate x=42
Followers -> Leader: ack
Leader -> Client: success

The client waits because correctness matters more than speed.

Eventual consistency: agreement, but not instantly

Now imagine a group chat. You send a message, and one friend sees it immediately while another sees it 2 seconds later. That's the intuition for eventual consistency: replicas may temporarily disagree, but if no new updates happen, they will converge to the same value.

This model is common when systems prioritize:

• low latency across continents
• high availability during network partitions
• massive scale, like millions of reads per second

Example: a product's like_count changes from 1200 to 1201 in Virginia. A user in Tokyo may still read 1200 briefly. That is acceptable if the number soon becomes 1201 everywhere.

Eventual consistency is often fine for:

• social media likes
• analytics dashboards
• product reviews

It is risky for:

• account balances
• inventory of scarce goods
• one-time coupon redemption

Choosing between them

Consistency is not about "good" versus "bad" design. It's about choosing the right guarantee for the job. A useful question is: What is the cost of a stale read?

Suppose a flash-sale system has 5 concert tickets left. If two replicas each still show 5, many buyers may proceed, and the system must later reject or refund some of them. Here, stale reads are expensive.

By contrast, if a news app's view counter says 10,004 on one server and 10,011 on another, users usually don't care.

A practical rule:

• choose strong consistency when incorrect reads break business rules
• choose eventual consistency when brief disagreement is acceptable and speed matters

Distributed systems are full of trade-offs. The best engineers don't ask, "Which model is better?" They ask, "Which mistake can this product afford?"