Since writing my previous article about the CAP theorem, I have come to realize that I may have misunderstood the CAP theorem and that consistency and availability could be potentially achieved(?).

While the CAP theorem asserts that consistency and availability cannot be achieved simultaneously in a distributed system, the CAP theorem defines availability and consistency in strict binary terms. The term “availability” is defined as a continuum and consistency can be divided into different levels, such as weak consistency, strong consistency, read and write consistency, and final consistency. In layman’s terms, the CAP theorem argues that strong consistency and ultimate availability cannot be achieved at the same time.

To address these limitations, Turing-award winning **Paxos Protocol **was introduced to maximize the efficiency of availability and consistency in such systems. Paxos algorithm helps systems work in the presence of network errors and node failures (availability) while ensuring consistency.

Paxos is a family of distributed algorithms for solving consensus in a network of unreliable or fallible processors.

The Paxos algorithm is based on simple majority rule which is capable of ensuring that only consistent resulting values can be achieved. The protocol proposes that if the majority of the nodes in a system are available, then the system as a whole is available and can guarantee strong data consistency, which is a great improvement for availability.

>> How it works

Essentially the Paxos protocol compares each write request to a proposal. In terms of entities, the Paxos protocol has the following entities:

1. Proposers: Receive requests (values/proposals) from clients and try to convince acceptors to accept their proposed values
2. Acceptors: Accept certain proposed values from proposers and let proposers know if something else was accepted. A response represents a vote for a particular proposal
3. Learners: Announces the outcome

Each proposal can be broken down into two phases: phase 1 (Prepare & Promise) and _phase 2 (Accept & Accepted). _Proposers interact with the acceptors twice.

1. **Phase 1: **Proposer selects a proposal number _n _and asks all acceptors to accept that _prepare request. _If acceptors receive a prepare request with number n and the value of n is greater than the number of all prepare requests it has already responded to, then it will guarantee that no proposal with a number less than n is accepted.
2. **Phase 2: **If the Proposer receives a response from the majority of Acceptors for its prepare requests (also as n), then it sends an _accept request _for the proposal with the number n and the value as v to Acceptors, where v is the value of the proposal with the highest number in the response received. If acceptors receive an accept request with a number n, it can accept the proposal as long as it has not responded to a _prepare request _with a number greater than n.

#algorithms #software-development #coding #programming #distributed-systems