ACID特性とCAP定理の「C」は全くの別物である
分散システムについて学習していた時、「整合性」という言葉の意味で混乱しました。調べてみたら、ACIDとCAPの「Consistency」は同じ単語なのに全く違う概念を指していました。
分散システムについて学習していた時、「整合性（Consistency）」という言葉の意味で混乱しました。
私は単一データベースの設計経験が長かったので、「整合性」と言えば「トランザクション後にデータが正しい状態になっているか」という意味だと思い込んでいました。でも、CAP定理の文脈では「ノード間でデータが同期されているか」という全く違う意味で使われていました。
同じ「整合性（Consistency）」という言葉なのに、全く別の概念を指していたことに気付きました。
調べてみて分かったこと
CAP定理を学習していて、「あれ、ACIDの『C』とCAPの『C』って別の意味じゃないか？」と気付きました。調べてみたら、やっぱり全然違いました。
ACIDのConsistency（私が最初に考えていた方）
これは「トランザクション後にデータがビジネスルールを満たしているか」という話でした。
例えば、銀行の送金処理で考えると：
// トランザクション開始BEGIN;
// AさんからBさんへ1000円送金UPDATE accounts SET balance = balance - 1000 WHERE user = 'A';UPDATE accounts SET balance = balance + 1000 WHERE user = 'B';
// コミットCOMMIT;このトランザクションが終わった後、以下のルールが守られているか？というのがACIDのConsistency：
- Aさんの残高がマイナスになっていないか
- 外部キー制約を違反していないか
- アプリケーションが定義したビジネスルールを満たしているか
私が最初に考えていたのは、まさにこれでした。
CAPのConsistency（CAP定理で言われている方）
これは「全てのノードが同じデータを見ているか」という話でした。
同じ送金処理で考えると：
// 東京サーバーに書き込みawait tokyo.update({ user: 'A', balance: 9000 });
// 直後に大阪サーバーから読み取りconst balance = await osaka.select({ user: 'A' });// → まだ10000円（古い値）が返ってくる可能性がある東京サーバーに書き込んだ瞬間、大阪サーバーでも同じ値が読めるか？というのがCAPのConsistency。
ネットワーク越しのレプリカ間の同期の話なので、ACIDとは全く別の次元の問題でした。
重要な違い
一番の気づきは、この2つでした：
| 比較軸 | ACIDの「C」 | CAPの「C」 |
|---|---|---|
| 前提 | 単一ノード | 複数ノード（分散） |
| 不整合の対象 | ビジネスルールとの矛盾 | レプリカ間のズレ |
ACIDは単一ノード、CAPは複数ノード前提という点が、一番の発見でした。同じ「整合性」という言葉を使うのに、対象が全く違います。
まとめ
分散システムについて学習していた時、「整合性」という言葉の意味で混乱しました。調べてみたら、ACIDの「C」とCAPの「C」は同じ単語なのに全く別の概念でした。
特に、ACIDは単一ノード、CAPは複数ノード前提で、不整合の対象も違います（ビジネスルール違反 vs レプリカ間のズレ）。この2つの違いを意識すると、分散システムの学習がスムーズになります。