Understanding CAP and BASE Through a Simple Network Partition Example

01 Imagine Two Data Centers

Assume a system has two data centers, Beijing and Shanghai, which normally synchronize data so that orders and profile updates are visible in both locations.

When the network between them suddenly fails, each data center remains alive but cannot communicate, creating a classic network partition problem.

02 Choices After a Partition

When a partition occurs the system must choose between two options.

Option 1: Both data centers continue serving users. Availability is high, but the two sites may write divergent data, leading to temporary inconsistency – this corresponds to the AP side of CAP.

Option 2: Only one data center is allowed to write while the other pauses part of its service. Consistency is stronger, but some users may be unable to use the system – this corresponds to the CP side of CAP.

The core of CAP is the trade‑off between strong consistency and high availability when a partition occurs.

03 What CAP Stands For

C = Consistency – all nodes see the same data.

A = Availability – every request receives a response, the system strives to stay up.

P = Partition Tolerance – the system continues operating despite network partitions, message loss, or node communication failures.

The most common misunderstanding is about P; it is not “network partition error” but the ability to tolerate partitions.

In real distributed systems P is unavoidable, so architects must decide whether to favor C or A when a partition happens.

04 When to Prefer CP

CP emphasizes consistency even if some requests become temporarily unavailable. Typical CP scenarios include financial transfers, inventory deduction, distributed locks, configuration centers, and strongly consistent metadata management. For example, a transfer must not result in money disappearing or balances diverging.

Zookeeper is a typical CP system; it acts as a “referee” that enforces rules rather than maximizing uptime for every client.

05 When to Prefer AP

AP emphasizes availability, allowing short‑term inconsistency. Common AP scenarios are homepage recommendations, comment likes, social feeds, product browsing, and service registries. For instance, a like count may briefly show 101 for one user and 100 for another before synchronizing.

Eureka is an example of an AP‑oriented service registry; stale entries are acceptable as long as the registry remains reachable.

06 Understanding BASE

BASE expands to Basically Available, Soft State, Eventually Consistent. In plain language: the system may degrade instead of crashing, intermediate states can be inconsistent, but the system eventually converges to a consistent state.

The philosophy is to keep the system alive first and synchronize later. During a large‑scale e‑commerce promotion, comment counts, recommendation results, or points can be updated with a delay, while core flows such as browsing, ordering, and payment must stay highly available.

07 Visual Summary

A simple diagram: Distributed system → network partition (P) → choose C (consistency) or A (availability). Choosing C leads to CP‑style systems (e.g., finance, inventory, locks, Zookeeper). Choosing A leads to AP‑style systems (e.g., homepage, likes, feeds, Eureka). BASE can be remembered as “Basically Available, Soft State, Eventually Consistent”.

08 Exam Answer Example

Question: During a major sales event, the system must stay browseable even if some nodes experience network issues, while comment counts and recommendation data may be temporarily inconsistent. Which side of CAP is more suitable?

Answer: AP, because the scenario prioritizes availability. The temporary inconsistency can be resolved with asynchronous sync, cache refresh, or message queues, matching the BASE philosophy.

09 Key Takeaways

CAP = Consistency, Availability, Partition tolerance; P is mandatory in real systems. When a partition occurs you must trade off C vs A. CP = consistency‑first; AP = availability‑first. Zookeeper is CP‑oriented; Eureka is AP‑oriented. BASE = Basically Available, Soft State, Eventually Consistent.

In short, after a network partition you either protect data integrity or keep the service alive – that is the essence of CAP.

10 Self‑Test

What do the three letters of CAP stand for?

Why must distributed systems usually consider P?

Are financial transfers better suited to CP or AP?

Are comment likes better suited to CP or AP?

What are the three words of BASE?

If you can answer without looking, you have passed Day 1.

Finally, the author reflects that CAP is not an abstract theory but a concrete design decision: when the network breaks, should the system protect data integrity or keep serving users?