Reflections on CAP Theory, ACID, BASE, and Cloud‑Native Fault Tolerance

“Believe everything you read is not as good as having no book.” – The author reflects on reading and proposes to discuss CAP theory, data consistency, fault tolerance, and disaster recovery.

CAP Theory Overview

CAP states that a distributed system can satisfy at most two of Consistency, Availability, and Partition tolerance. The article explains the three possible trade‑offs (CA without P, CP without A, AP without C) and gives examples from traditional databases, NoSQL systems, and large‑scale internet services.

ACID Extension

ACID consists of Atomicity, Consistency, Isolation, Durability. The author describes how consistency in ACID ensures logical data rules and mentions that systems like Google Spanner provide both ACID and CAP guarantees via two‑phase commit and Paxos replication.

BASE Extension

BASE (Basically Available, Soft state, Eventual consistency) is presented as a practical alternative to strong consistency, used by many distributed systems such as asynchronous MySQL replication.

Rethinking CAP Objects

The author argues that the original CAP objects (database, software, network) are outdated for modern distributed systems and suggests upgrading the concepts to Consistency, Fault tolerance, and Disaster tolerance.

Impact of Cloud‑Native

Cloud‑native infrastructure changes how fault tolerance and disaster recovery are designed. The article discusses the shift from over‑design to SLA‑driven resilience, the role of micro‑services, containers, and DevOps, and how cloud providers’ SLAs affect disaster‑recovery strategies.

Fault‑Tolerance Basics

Fault tolerance is defined as the ability to tolerate errors (code bugs, system failures, user misuse). The author provides a C code example that checks the return value of fork() and logs an error.

if ((pid = fork()) < 0){
    // strerror returns a string describing the error.
    fprintf(stderr, "fork error: %s\n", strerror(errno));
    exit(0)
}

Various fault‑tolerance techniques (retry, graceful degradation, user prompts) are compared, and the importance of identifying uncertainty (errors vs. disasters) is emphasized.

Future Outlook

The author envisions algorithm‑driven self‑healing systems that learn from large amounts of exception data to automatically design fault‑tolerance measures.