CAP 描述 network partition 發生時的行為：replicated service 不能同時保證 linearizable response，以及每個 non-failing node 都成功回覆。它不是 database 永久「三選二」。
先說清楚 client 看得到什麼
| Model | Client-visible promise |
|---|---|
| Linearizability | Operation 像在 call／return 間某一瞬間發生 |
| Sequential consistency | 單一 global order 尊重各 client program order |
| Causal consistency | 保留 causal order；concurrent write 可不同 |
| Eventual consistency | Update 停止後最終 converge，沒有 freshness bound |
Consistency 不是 strong／weak slider；每個 model 允許的 observation 不同。
Quorum 顯示可調邊界
Replication factor (N)、write acknowledgements (W)、read responses (R) 下，(R + W > N) 會產生 overlap。Correctness 仍取決於 version selection、failure assumption、sloppy quorum 與 repair；不等式本身不是完整 proof。
Cassandra write path
Cassandra 將 key partition 到 ring，並跨 failure domain replication。Replica append commit log、update memtable，之後 flush sorted SSTable。Bloom filter 避免搜尋確定不含 key 的 SSTable；compaction merge file 並清 obsolete version。
Hinted handoff、read repair、anti-entropy 幫 replica converge；tunable consistency 決定 request 等多少 replica response。
HBase 選不同 contract
HBase 將 ordered row 放在 HDFS-backed region。Region server 維護 WAL／MemStore，再 flush HFile；range scan 使用 row-key order。Coordination 與 single-region ownership 偏向強 consistency，partition 時受影響 region 可能 unavailable。
白話來說： Cassandra 傾向故障時多開幾扇門、之後 reconcile；HBase 寧可關門，也不提供互相衝突的 view。
從 access 與 failure behavior 設計
Partition key、row key、consistency level、replica placement 要一起選。要問 client 在 own write 後能讀到什麼、region／rack failure 時怎麼辦、conflict 如何表示，以及 convergence 最久多久。
複習卡
- CAP 特別描述 communication partition。
- Consistency model 是允許 observation 的集合。
- Quorum overlap 仍需相容 version／repair rule。
- Cassandra 使用 append、memtable、SSTable 與 background repair。
- HBase 使用 ordered region，偏向只從 available owner 提供 consistent access。
- Storage layout 與 consistency contract 必須一起符合 workload。