What is consistency?

Consistency is the guarantee that every read of data returns the same value that was last written, no matter where or when you look at it. In simple terms, it means “what you see is what’s really there” and that the data doesn’t unexpectedly change or become out‑of‑sync.

Let's break it down

  • Strong consistency - every read sees the most recent write instantly.
  • Eventual consistency - updates spread over time; reads may see older data, but all replicas will converge eventually.
  • Read‑your‑writes - a special case where a user always sees their own recent changes, even if the system is only eventually consistent for others.
  • Monotonic reads/writes - once you’ve seen a value, you won’t see an older one later; writes are applied in order.

Why does it matter?

Consistent data prevents errors, confusion, and lost information. When a banking app shows the wrong balance or a collaborative document shows different versions to teammates, trust in the system erodes. Consistency also makes debugging easier because the state you observe matches the state you expect.

Where is it used?

  • Relational databases (SQL) that enforce strong consistency.
  • Distributed key‑value stores (e.g., DynamoDB, Cassandra) that often use eventual consistency for speed.
  • Caching layers (Redis, Memcached) where consistency rules decide when cached data is refreshed.
  • Microservice architectures where services share state through APIs or message queues.
  • Real‑time collaboration tools (Google Docs, Figma) that blend different consistency models to keep users in sync.

Good things about it

  • Reliability: Users can trust the information they receive.
  • Predictability: System behavior is easier to reason about and test.
  • Data integrity: Prevents duplicate or conflicting records.
  • Simpler application logic: Developers don’t need extra code to handle stale or conflicting data.

Not-so-good things

  • Performance cost: Strong consistency often requires extra network round‑trips and locking, slowing down responses.
  • Scalability limits: Maintaining strict consistency across many nodes can become a bottleneck.
  • Complexity in distributed setups: Designing a system that balances consistency, availability, and partition tolerance (CAP theorem) is challenging.
  • Higher latency: Users may experience delays while the system ensures the latest data is visible.