Consistency
Understand This First
- Transaction – transactions are the primary mechanism for maintaining consistency.
- Atomic – atomic operations prevent data from being observed in an inconsistent state.
- Source of Truth – a designated source of truth is the reference point for consistency.
- Database – databases provide the constraints and mechanisms that enforce consistency.
Context
A system with a Database, State, and multiple users or components needs to present a coherent picture of reality. Consistency means that data and observations agree according to the system’s rules: an account balance reflects all completed transactions, an inventory count matches actual stock, and two services looking at the same data see the same answer. This is an architectural pattern because consistency requirements shape database choices, system design, and communication protocols across the whole application.
Problem
How do you ensure that all parts of a system, and all users looking at the system, see data that agrees with itself and with the system’s rules?
Inconsistency is surprisingly easy to create. Two users buy the last item in stock at the same moment, and the system shows both purchases as successful, but there’s only one item. A service updates a customer’s address in one database while the notification service reads the old address from its cache. A background job recalculates totals while a user is in the middle of adding items. The results make no sense, and users lose trust.
Forces
- Strong consistency (everyone always sees the latest data) requires coordination, which is slow.
- Weak consistency (allow temporary disagreements) is fast but can confuse users and create bugs.
- Distributed systems, where data lives on multiple machines, make consistency fundamentally harder.
- The cost of inconsistency depends on the domain: a stale social media feed is annoying; a stale bank balance is dangerous.
Solution
Define your consistency requirements explicitly, based on the domain. Not all data needs the same level of consistency. A bank balance needs strong consistency: every transaction must be reflected immediately and accurately. A social media “like” count can tolerate brief staleness. It’s fine if it takes a few seconds to update.
For data that requires strong consistency, use the tools databases provide: Transactions to group related operations, Atomic operations to prevent partial updates, constraints and foreign keys to enforce relationships, and locks or versioning to prevent concurrent modifications from conflicting.
For data where some staleness is acceptable, use eventual consistency, the guarantee that all copies will converge to the same value given enough time. Caches, read replicas, and denormalized copies operate this way. Be explicit about which data follows which model, so developers don’t accidentally treat stale data as authoritative.
In distributed systems, the CAP theorem tells us that during a network partition, you must choose between consistency and availability. This isn’t a theoretical concern. It’s a design decision you make when choosing between database technologies and replication strategies.
How It Plays Out
An e-commerce site runs a flash sale. Two customers simultaneously add the last unit to their carts and click “buy.” Without proper consistency controls, both orders go through and the warehouse ships an item it doesn’t have. With a transaction that checks inventory and decrements it atomically, only one order succeeds. The other gets an “out of stock” message — disappointing but correct.
When an AI agent generates code that reads from a cache and writes to a database, it may not realize the cache and the database can disagree. If the agent builds a “check balance, then debit” flow that reads the balance from a cache, the check might pass even though another process already debited the database. Telling the agent to “always read from the database for operations that require current data” prevents this class of bug.
AI agents often generate code that reads and writes without considering concurrency. Any operation that reads a value, makes a decision based on it, and then writes a result is vulnerable to race conditions. Look for these read-then-write patterns in generated code and wrap them in transactions.
“The check-balance-then-debit flow has a race condition. Wrap the read and write in a database transaction with a row-level lock so two concurrent requests can’t both pass the balance check.”
Consequences
Strong consistency gives users and developers confidence that the data they see is real and current. It prevents an entire class of bugs related to stale reads, lost updates, and phantom data. It simplifies reasoning about system behavior.
The cost is performance and availability. Consistency requires coordination (locks, transactions, consensus protocols), and coordination takes time. In distributed systems, demanding strong consistency means the system may become unavailable when network issues occur. The practical answer is almost always a mix: strong consistency for critical data, eventual consistency for everything else, and clear documentation about which is which.
Related Patterns
- Uses / Depends on: Transaction — transactions are the primary mechanism for maintaining consistency.
- Uses / Depends on: Atomic — atomic operations prevent data from being observed in an inconsistent state.
- Uses / Depends on: Source of Truth — a designated source of truth is the reference point for consistency.
- Uses / Depends on: Database — databases provide the constraints and mechanisms that enforce consistency.
- Refined by: Data Normalization / Denormalization — normalization reduces the surface area for inconsistency.
- Contrasts with: Idempotency — idempotency is a different strategy that makes operations safe to retry, complementing consistency.