CAP主要是探討 資料分區 (Partition) 的問題，當為了分散流量處理而新增多個資料庫節點時，每個節點的資料勢必要保持一致，才不會導致有時使用者取得到的是最新資料，有時取得到舊資料，但世界上不存在100%穩定的網路，有時會因為延遲或斷線導致資料庫之間的資料不一致，這就是CAP主要探討的議題。
CAP定義
CAP主要有以下三種條件
- C 一致性 (Consistency)：使用者Always拿到最新的資料，所有分散式節點對同一份資料的讀取操作，都應該返回相同的值。
- A 可用性 (Availability) : 使用者Always在有限時間內得到回應。
- P 分區容錯性 (Partition tolerance) : 即使發生網路分區，系統也應該要能夠繼續運作。
CAP的選擇
CAP定理告訴我們，在分散式系統中，不可能同時滿足ＣＡＰ三種條件，只能選擇其中兩種條件來滿足。
CA 一致性、可用性（最不考慮）
不考慮CA是因為，若要滿足這兩個條件，必須確保各個節點的資料必須100%同步，且100％可用不出錯，這代表網路環境必須100%穩定才可實現，或是直接使用單一資料庫的架構（不必考慮資料庫間的網路問題），但這樣的做法就失去了CAP的意義，因此不考慮CA的組合。
CP 一致性、分區容錯性
每個節點的讀寫都是最新的資料，也就是達成一致性，但又要在資料分區的狀況下讓系統正常運作，這意味著，必須犧牲掉可用性（Always取得回應），當資料分區時，我們沒辦法給予最新的資料，因此使用者的請求會直接失敗，沒有任何一個資料庫會片面地改變資料的狀態。
我們保證了資料的C（一致性），但犧牲了使用者總是能得到回應的A（可用性）。
AP 可用性、分區容錯性
使用者Always得到回應，同時又要在資料分區狀況下讓系統正常運作，當使用者要新增資料到某個資料庫節點，但因為網路分區造成其他資料庫沒有即時同步，為了滿足Always得到回應，因此犧牲掉C (一致性) ，仍然將資料更新至該節點。
使用場合
強一致性 (String Consistency)
即為CP，對於一致性要求較高，可以容忍暫時不可用的應用，像是金融交易這類的，資料需要保持一致的場合。
最終一致性 (Eventually Consistency)
即為AP，顧名思義就是“最後”才會保持一致，不必要求當下每個資料庫節點的資料就要立即一致，像是遇到網路暫時中斷或延遲，沒有即時同步資料到其他資料庫，還是可以讓使用者繼續存取資料得到回應（不是最新的資料也沒差），這種會應用在文章留言、影片觀看次數、社交媒體、內容轉發等場合。