CAP, PACELC and Quorums

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Decide what happens when copies disagree: strong, read-your-writes and eventual consistency, what CAP really says, PACELC's latency trade-off, and N, W, R quorums with the R + W > N rule.

Imagine a bakery with two branches that share the same stock book. Whenever a cake is sold, one branch updates the other so that both stock books remain synchronized.

One afternoon, the connection between the branches stops working. A customer at branch B wants the last chocolate cake. Branch B now has two choices:

• Refuse the sale: "Sorry, we cannot verify stock right now." The stock remains correct, but the customer leaves disappointed.
• Allow the sale: the customer is happy, but branch A may have already sold that last cake.

While communication between the branches is broken, there is no perfect solution.

This situation captures the core idea behind the CAP theorem.

The main idea: when copies of data cannot communicate, a system must choose between always giving the correct answer and always giving an answer. Different features may require different choices.

What You Will Learn

In this lesson, you will learn:

1. Why copies of data can disagree.
2. Three common consistency models: strong consistency, read-your-writes consistency, and eventual consistency.
3. What the CAP theorem actually means.
4. How PACELC extends CAP by describing trade-offs during normal operation.
5. How quorums (N, W, and R) work.
6. Why the rule R + W > N matters.
7. Which QuickBite features should prioritize correctness and which should prioritize availability.

Why Copies Disagree

QuickBite stores multiple copies of important data, often across different servers, regions, or data centers.

Whenever data changes, the update must travel across the network. This takes time, and networks can fail.

As a result, different copies of the same data can temporarily contain different values.

The important question is:

What guarantees does the system provide during that period?

Consistency Models

A consistency model describes what values a read request is allowed to return.

The three most common models are:

Eventual Consistency in Action

A rating changes at 0 ms. Each copy hears about it after its own delay: Mumbai at once, Chennai after 120 ms, Delhi after 400 ms. Step through it:

For a short period, users may see different ratings depending on which copy they read from.

For ratings, this is usually acceptable.

For a bank account balance or payment record, it would be a serious problem.

The CAP Theorem

The Three Letters

CAP stands for:

• Consistency (C): every read receives the latest write.
• Availability (A): every request receives a response.
• Partition Tolerance (P): the system continues operating when communication between copies fails.

A communication failure between copies is called a network partition.

What CAP Really Says

CAP is often explained as:

"Pick any two of the three."

This explanation is misleading.

Network failures are unavoidable in distributed systems, which means partition tolerance is not optional.

A more accurate interpretation is:

When a network partition occurs, you must choose between consistency and availability.

Choose Consistency

Some requests are rejected until the system can confirm the correct answer.

Benefits:

• Data remains correct.

Drawbacks:

• Some requests fail.

Choose Availability

Every request receives a response.

Benefits:

• System remains available.

Drawbacks:

• Some responses may be outdated.

When the network is healthy, many systems can provide both consistency and availability.

The wrong way first: choose availability for inventory

One portion of the special biryani is left, and the network between the copies is down. Step through it, first the wrong way and then the right way:

In the wrong way, the Mumbai customer and the Chennai customer both hear "sold". Portions sold: 2. Portions that existed: 1.

Both copies sold the same item, creating an impossible inventory state.

Eventually someone receives an apology and a refund.

The right way: require a majority

The last steps of the animation show the fix. With 3 copies, a sale needs a majority: 2 of 3.

Only the side that can communicate with a majority of copies can process the sale.

Since both sides cannot simultaneously have a majority, the last item can only be sold once.

Choosing for QuickBite

In simple terms: when communication fails, money and inventory should prioritize correctness, while informational features can remain available.

PACELC: Trade-Offs During Normal Operation

CAP focuses only on network failures.

PACELC extends the discussion by considering what happens when the network is healthy.

PACELC stands for:

• If there is a Partition (P): choose Availability (A) or Consistency (C).
• Else (E): choose Latency (L) or Consistency (C).

Even when there is no network partition, maintaining stronger consistency often increases response time because more replicas must acknowledge requests.

Say the Mumbai leader has three copies: one in the same building (2 ms away), one in Chennai (30 ms) and one in Singapore (150 ms). The chart shows how long a write waits:

The stronger the consistency requirement, the more copies the system may need to wait for.

As a result, stronger consistency often increases latency.

This is the Latency versus Consistency trade-off described by PACELC.

Quorums: Choosing the Balance

N, W and R

Many distributed databases use three quorum values:

• N = total number of copies.
• W = number of copies required to confirm a write.
• R = number of copies consulted during a read.

Different values create different balances between consistency, latency, and availability.

The Overlap Rule

The most important quorum rule is:

R + W > N

When this rule is true, every successful read overlaps with every successful write.

That overlap guarantees that reads can see the latest data.

The figure compares four choices of W and R with N = 3. It shows whether a read is sure to be fresh, and how many copies can be down while writes and reads still work:

Here is the same idea in code:

R + W > N decides whether a read is sure to see the latest write

const n = 3;
const choices = [
  { w: 1, r: 1 },
  { w: 2, r: 1 },
  { w: 2, r: 2 },
  { w: 3, r: 1 },
];

for (const { w, r } of choices) {
  const safe = r + w > n;
  console.log(`W=${w} R=${r}: R+W=${r + w} ${safe ? "> 3, always fresh" : "<= 3, may be stale"}`);
}

Expected output:

W=1 R=1: R+W=2 <= 3, may be stale
W=2 R=1: R+W=3 <= 3, may be stale
W=2 R=2: R+W=4 > 3, always fresh
W=3 R=1: R+W=4 > 3, always fresh

When the overlap rule is not satisfied, reads may accidentally query only replicas that missed the newest update.

How Many Copies Can Fail?

Increasing R and W improves consistency, but requires more replicas to be available. Writes work while N − W copies are down, and reads while N − R are down:

A common configuration is:

• N = 3
• W = 2
• R = 2

This configuration provides:

• Strong read/write overlap.
• Tolerance for one failed replica.
• Fresh reads.

Try It: Quorums with Three Replicas

Experiment by changing W and R values.

Then simulate a network partition and observe which reads and writes still succeed.

Common Mistakes

Practice

What to Remember

• Copies of data can disagree because updates take time to travel and networks can fail.
• Strong consistency always returns the latest data.
• Read-your-writes consistency guarantees that users see their own updates.
• Eventual consistency guarantees that replicas become consistent over time.
• CAP states that during a network partition, systems must choose between consistency and availability.
• PACELC explains that even without failures, stronger consistency often increases latency.
• Quorums use N, W, and R to balance consistency and availability.
• R + W > N guarantees overlap between reads and writes.
• Use consistency for money and inventory. Use availability for menus, ratings, and similar user-facing information.

Further Reading

These are the sources this lesson was checked against:

• Eric Brewer: CAP Twelve Years Later: the author of CAP explains why "pick two" is misleading.
• Daniel Abadi: Consistency Tradeoffs in Modern Distributed Database System Design (PACELC): the paper that adds the latency trade-off.
• Amazon's Dynamo paper (2007): N, W and R quorums in a real shopping-cart system.
• Designing Data-Intensive Applications (Martin Kleppmann): consistency models and quorums explained in depth.

Next: Queues, Streams and Idempotency, where QuickBite learns how to handle slow operations asynchronously and ensure an order is never charged twice.