ACID特性とCAP定理の「C」は全くの別物である

この2つは、議論のフィールドが根本的に異なります。

ACIDは「単一ノード」の話

1970年代、データが1台のサーバーに収まっていた時代の思想です。

「その1台の中で、いかにデータを正しく保つか」を議論しています。

• トランザクションが終わった後、データがビジネスルール（制約・バリデーション）を満たしているか？
• 例：「残高がマイナスにならない」「外部キーが存在する」といったアプリケーション定義のルールとの整合性

CAPは「複数ノード（分散システム）」の話

2000年代以降、データを複数のサーバーにコピーして持つのが当たり前になった時代の思想です。

「ネットワーク越しに複数のノードが、同じデータを見ているか」を議論しています。

• あるノードに書き込んだ直後、別のノードから読んでも同じ値が返るか？
• 例：東京サーバーに書いた瞬間、大阪サーバーでも同じ値が読めるか？というレプリカ間のズレの問題

前提が違えば、「何が不整合か」の定義も変わります。

ACIDの不整合：ビジネスルールとデータの矛盾

ACIDが守ろうとするのは、アプリケーションが定めたルールとデータの整合性です。

• 「残高がマイナスになってはいけない」というルールが存在するにも関わらず、トランザクションの途中で残高が-500円になった状態。
• 外部キー制約があるにも関わらず、参照先が存在しないレコードが生まれた状態。

**不整合の相手は「コード・スキーマに書かれたビジネスルール」**です。

CAPの不整合：レプリカ間のズレ

CAPが問うのは、複数のノード間でデータの値が一致しているかどうかです。

• 東京ノードに「残高: 1000円」と書き込んだ直後、大阪ノードを読んだら「残高: 2000円（古い値）」が返ってきた状態。
• ビジネスルール上は何も問題ない。ただ、ノード間でデータがズレている。

**不整合の相手は「別のノードが持つコピーデータ」**です。

**ACIDはProperty（特性）**です。「こういう性質を持つシステムを作ろう」という設計目標であり、達成できるかどうかは実装次第です。

**CAPはTheorem（定理）**です。「ネットワーク分断が起きたとき、一貫性と可用性を同時に満たすことは数学的に不可能」という、どんな工夫をしても逃れられない物理法則です。

ACIDの「C」は努力で達成できる目標。CAPの「C」はトレードオフの対象。同じ言葉で全く異なるレイヤーの話をしています。

• ACIDのC = 「トランザクション後、データがビジネスルールを守っているか」（単一ノード、設計目標）
• CAPのC = 「全ノードが同じデータを見ているか」（分散システム、物理法則）