Data consistency means the same data looks the same everywhere. A customer's address in the billing system matches the address in the shipping system. The inventory count in the warehouse matches the count on the website. When systems disagree, decisions go wrong. Orders ship to old addresses. Customers buy products that are out of stock. Consistency is not optional for systems that depend on each other.

Distributed systems make consistency hard. Data replicated across multiple servers can fall out of sync. A network partition isolates one region from another. Both regions accept writes. When the partition heals, the data conflicts. The CAP theorem says you can have consistency, availability, and partition tolerance, but not all three at once. Most distributed databases choose availability and eventual consistency. That means the data converges over time, but there is a window where different nodes see different values. Strong consistency requires coordination, which costs latency. The choice depends on the application. A banking ledger needs strong consistency. A social media feed can tolerate eventual consistency. The right answer is not universal. It depends on what breaks when the data disagrees.

Consistency models

• Strong — all nodes see the same data immediately
• Eventual — nodes converge over time
• Causal — related operations are seen in order
• Read-your-writes — you see your own updates immediately

Consistency is a spectrum. The question is how much inconsistency the application can tolerate before it breaks.