CAP questions almost never appear labeled as “CAP theorem.”
They show up disguised as simple data questions.
This is one of the trickiest questions I have heard in system design interviews:
Can a system be accurate but inconsistent?
Many candidates pause here because the phrase sounds like an oxymoron; something contradictory that shouldn’t even be possible.
It is not.
Understanding this possibility is important because distributed systems constantly separate accuracy & consistency.
And once systems scale across replicas and regions, the gap between accuracy and consistency becomes impossible to ignore.
To see why, we first need to define what those terms actually mean.
The best way to build any app
Most “AI app builders” aren’t actually app builders. They are infrastructure middlemen. You live inside their box, choose from their secret stack, and force you to start over the moment you want to use a different database, payment processor, or tool. With Orchids:
You’re not locked-in to Supabase or Stripe.
Not forced to spend credits, bring your own AI subscriptions with you.
One-click deployment straight to Vercel
Build anything. From Web, mobile, internal tools, browser extensions, scripts, and bots. Orchids.app is capable of building anything that you can put your mind to.
Use code MARCH15 for 15% off (one-time discount).
Accuracy vs Consistency
Let’s start with the definitions.
Accuracy means the data reflects the real-world value.
Consistency can mean different things depending on context.
In casual conversations, engineers sometimes mean “replicas return the same value.”
In the CAP theorem, consistency specifically refers to linearizability, where reads always see the most recent committed write.
In a single database running on one machine, these usually appear together.
The correct value is written once, and every read returns that same value.
But distributed systems introduce replication.
Multiple nodes store copies of the same data.
Those copies must stay synchronized.
That synchronization delay is exactly where accuracy and consistency begin to diverge.
The confusion happens because small systems usually give you both properties at the same time.
And the easiest way to see that is through a very common scenario: a system that is accurate but temporarily inconsistent.
Accurate but inconsistent
This situation happens constantly in distributed systems.
Imagine a user updating their email address.
Now imagine a read request arrives during that replication window.
The primary database returns the new email.
A replica still returns the old one.
Some users see the new value.
Others see the old one.
The system already contains the correct value, so it is accurate.
But the nodes do not agree yet, so it is inconsistent.
This behavior appears in systems using:
read replicas
multi-region databases
asynchronous replication
eventual consistency models
The inconsistency usually resolves itself once replication finishes.
But not all inconsistencies are temporary. In fact, the more dangerous scenario is when a system becomes perfectly consistent while being completely wrong.
Consistent but inaccurate
Now consider a different situation.
A bug writes the wrong tax rate.
Every node returns the same number.
The system is now perfectly consistent.
But the number itself is incorrect.
Consistency guarantees agreement about the relative order of reads and writes as observed by clients, in a way that behaves like a single global log.
It does not guarantee correctness.
A distributed system can synchronize bad data just as efficiently as good data.
This is why strong consistency does not protect a system from logical errors.
And that leads to one of the most common misunderstandings engineers have about the CAP theorem.
The CAP misconception
Many engineers assume strong consistency prevents incorrect data.
But that’s not what the CAP theorem promises.
In the CAP theorem, consistency refers to linearizability: every read appears to see the most recent completed write as if all operations happened in a single global order.
This is different from the everyday meaning of “replicas having the same value” or SQL-style consistency constraints.
If the write itself is wrong, the system will consistently return the wrong value everywhere.
In other words:
Consistency protects agreement about the order of writes, not the truth of the data itself.
Truth depends on things like:
application validation
business rules
transactional safeguards
domain logic
Distributed systems coordinate during and after writes so nodes agree on the result.
Many production systems relax this guarantee and instead provide eventual consistency, where replicas may temporarily diverge but converge over time.
But that agreement comes at a cost, because coordinating nodes across machines or regions is never free.
The latency tax of coordination
Strong consistency requires nodes to coordinate before confirming a write.
A typical strongly consistent write looks like this:
Each additional replica adds more communication.
Across regions, this becomes expensive.
A write that takes 5 ms locally might take 80–200 ms globally.
At scale, that latency affects user experience.
To avoid that cost, many distributed systems allow writes to succeed without waiting for every replica to confirm.
Updates propagate asynchronously.
This reduces latency but introduces temporary inconsistency.
Strong consistency requires coordination between nodes before a write is considered committed.
Most distributed databases implement this using quorums or consensus protocols, where a majority of replicas must acknowledge the write.
And different products choose different approaches depending on what matters most for the system.
Why systems choose different trade-offs
Architecture decisions always depend on the domain.
Some systems must guarantee correctness immediately.
Others must prioritize speed and availability.
Systems that require strong consistency
These domains cannot tolerate incorrect values:
banking balances
payment processing
financial ledgers
inventory reservations
If two nodes approve the same payment simultaneously, the system could double-charge a user.
To prevent that, these systems accept the latency cost of coordination.
Correctness with respect to business invariants must be guaranteed before a transaction commits.
But not every system faces that constraint.
Systems that accept eventual consistency
Other domains prioritize responsiveness and global scale:
social feeds
analytics dashboards
recommendation engines
caching layers
If a post appears a few seconds later in another region, the user experience barely changes.
But forcing every write to coordinate globally would slow the system dramatically.
These architectures allow temporary inconsistency while updates propagate across replicas.
Eventually, all nodes converge to the same value.
And that design decision reveals the real lesson behind CAP.
The real lesson of CAP
The CAP theorem often appears in textbooks as a theoretical concept.
In practice, it represents a constant architectural choice.
Every distributed system must balance:
coordination cost
latency
availability
correctness guarantees
At a small scale, these trade-offs are easy to ignore.
But once systems span multiple replicas, regions, and networks, they become unavoidable.
Which is why the real challenge in system design isn’t eliminating trade-offs.
It’s deciding which trade-off hurts the least.
Final thought
Distributed systems will always contain imperfections.
Nodes fail.
Networks partition.
Replication lags.
You cannot design those problems away.
But you can decide how the system behaves when they happen.
A system can be:
accurate but temporarily inconsistent (replication lag)
consistent but permanently wrong (a bad write replicated everywhere)
both inaccurate and inconsistent (bugs combined with replication delay)
And the architecture determines which one occurs.
Good engineers don’t try to build perfect systems.
They design systems where the inevitable failure mode causes the least damage.
Because at scale, system design isn’t about perfection.
It’s about choosing the right compromise.
Until next time,
— Raul
System Design Classroom is a reader-supported publication. To receive new posts and support my work, consider becoming a paid subscriber.