CAP vs BASE: Picking the Right Consistency Model for MySQL, Redis & Elasticsearch

CAP Theorem

In a distributed system only two of the three properties—Consistency, Availability, and Partition tolerance—can be satisfied simultaneously; the third must be sacrificed.

Consistency

All nodes see the same data at the same time (strong consistency). It can be relaxed to weak consistency or eventual consistency, where updates become visible after some delay. For example, when user A transfers 100 ¥ to user B, both accounts must reflect the change instantly under strong consistency.

Availability

Every read or write request receives a response, regardless of the system’s state, meaning the system continues to serve requests successfully within a bounded time.

Partition Tolerance

The system remains operational despite arbitrary network partitions or failures of part of the cluster, continuing to provide either consistency or availability depending on the chosen trade‑off.

BASE Theorem

BASE extends the AP side of CAP by defining "Basically Available" + "Soft state" + "Eventually consistent". It accepts temporary loss of availability to guarantee core functionality, allows intermediate data states without breaking overall availability, and ensures that all updates eventually converge to a consistent state.

Mapping Transactions to CAP/BASE

Rigid (strong) transactions such as 2PC and 3PC satisfy the CP requirements of CAP, while flexible transaction patterns like TCC, SAGA, local message tables, transaction messages, and best‑effort notifications align with the BASE approach.

MySQL Replication Modes

MySQL supports three replication modes:

Asynchronous replication – default mode; writes are acknowledged after the master writes to the binlog, without waiting for slaves. This is an AP configuration and can lead to data inconsistency during network partitions.

Semi‑synchronous replication – the master waits for at least one slave to acknowledge receipt of the binlog event before responding to the client. It still prioritises availability over strict consistency, thus belonging to the AP model.

Full synchronous replication – the master waits for all configured slaves to confirm the binlog event before returning success, guaranteeing consistency at the cost of availability, i.e., a CP configuration.

The write flow involves the master recording changes to the binlog, optionally waiting for slave acknowledgments, and the slave applying the changes via its relay log.

Redis Cluster

Redis Cluster’s master writes each command to a replication‑offset buffer and updates its offset. The master then streams commands to slaves over TCP without waiting for acknowledgments. Replication offsets and the circular buffer allow slaves that reconnect after a network glitch to receive only the missing commands, achieving eventual consistency. Because it does not block writes for full consistency, Redis Cluster operates under the AP model.

Elasticsearch Cluster

Write operations are routed from the coordinating node to a primary shard, which then replicates the change to replica shards. Consistency is controlled by the consistency parameter with three options: one – only the primary shard must acknowledge. quorum – a majority of primary and replica shards must acknowledge (default). all – all shard copies must acknowledge, enforcing strong consistency (CP).

When consistency=all, the cluster behaves as CP; otherwise, it follows the AP model.

Understanding these trade‑offs helps engineers select the appropriate replication strategy and consistency level for their specific workload and failure tolerance requirements.