“Consistency” is one of those overloaded terms in computer science. It shows up in ACID transactions and in the CAP theorem, but it means very different things depending on the context. Let’s unpack the difference.
Consistency in ACID
In the ACID world, consistency is really about data integrity. It guarantees that once a transaction finishes, the database is left in a valid state that respects all the rules defined for it. These rules form a kind of contract — but it’s important to recognise that not all parts of the contract are enforced in the same place:
1. Database-managed consistency
Relational databases natively enforce the structural rules that keep data coherent:
• Entity integrity: every table must have a unique primary key, so no two rows can pretend to be the same entity.
• Referential integrity: foreign keys must actually point to valid records. If you try to insert an order for a customer that doesn’t exist, the DB will reject it.
• Domain integrity: values must fit their declared type or constraints. A DateOfBirth column must really contain valid dates, and a CHECK (age >= 0) constraint will prevent nonsense values.
These guarantees are what people usually mean when they talk about “ACID consistency”: the database won’t let transactions leave behind broken references, duplicate entities, or invalid values.
2. Application-managed consistency
Not all rules can live in the schema. Some depend on business context that the database can’t infer:
• A salary must be less than the manager’s salary.
• A user can’t book overlapping appointments.
• An account balance must never go below zero.
These are examples of user-defined integrity. You can sometimes push them into the database with triggers, stored procedures, or clever constraints, but in practice many teams handle them at the application layer, where the domain knowledge already sits.
ACID consistency isn’t just a vague promise — it’s the database actively defending certain integrity guarantees (entity, referential, domain), while leaving higher-order business rules (user-defined integrity) to the application. An important point to bear in mind is that consistency relies on atomicity and isolation — without them, a database could not reliably preserve its integrity rules.
So: ACID consistency = data integrity within a single database system.
Consistency in CAP
Now shifting gears to distributed systems.
In the CAP theorem, consistency takes on a completely different meaning. Here, it’s about replica agreement: ensuring that no matter which server or node you connect to, you see the same, most up-to-date data.
If you change your profile picture in a global social network, CAP consistency asks: will someone connecting in London and someone in Sydney both see the new photo immediately? Or will one of them still see the old one for a while?
This kind of consistency isn’t about schema validity or business rules. It’s about keeping replicas in sync when the system is spread across machines, data centers, or even continents. And because network partitions can and do happen, distributed systems have to make hard choices between prioritising availability to clients even if some nodes serve stale data or prioritising consistency even if that means refusing some requests during a network partition.
So: CAP consistency = agreement on data across distributed nodes.
Putting It Together
An ACID-compliant database ensures correctness inside the box — your data won’t violate constraints, even if you crash mid-transaction.
But when you deploy that database in a distributed setting, you can’t escape CAP. Network partitions are a fact of life. You’ll still need to decide: do you sacrifice availability to make sure all replicas agree, or do you risk stale reads for the sake of uptime?
They share the same word, but they live in different problem spaces. Both are essential — one for trust in your data, the other for trust in your system.