What are the CAP theorem trade-offs for CouchDB — is it CP or AP?

CouchDB is an AP system — it prioritizes Availability and Partition tolerance over strict Consistency. When a network partition occurs, CouchDB nodes on either side continue accepting reads and writes rather than refusing requests to maintain linearizability. The result is that two nodes can hold diverged versions of the same document (called open conflicts) until replication heals the partition.

CouchDB's consistency model is eventual consistency: after a partition heals and replication runs, all nodes converge. The conflict resolution mechanism — the deterministic winning-revision algorithm plus application-level merge — is how convergence is achieved without a global coordinator.

The AP versus CP distinction surfaces in these specific scenarios:

• Multi-master replication — both nodes independently accept writes to the same document. The replication protocol syncs them and surfaces the conflict for application resolution.
• CouchDB 3.x cluster quorum settings — the write quorum w and read quorum r default to a majority of n replicas. Raising both to n makes the cluster refuse writes when a node is down, shifting behavior toward CP at the cost of availability.

This AP design is the reason CouchDB excels in offline-first and mobile applications via PouchDB: the mobile client writes locally (always available) and syncs to the server when connectivity returns, with conflicts resolved deterministically.