2nd/10_Wiki/Topics/Architecture/ACID Transactions.md

---
id: wiki-2026-0508-acid-transactions
title: ACID Transactions
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [ACID, Database Transactions, Atomicity Consistency Isolation Durability]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
verification_status: applied
tags: [database, transactions, consistency, postgres]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: sql
  framework: postgres-17
---

# ACID Transactions

## 매 한 줄
> **"Atomicity / Consistency / Isolation / Durability — 매 transaction 의 four guarantees."** Härder & Reuter (1983) 가 정식화한 properties. 매 RDBMS (Postgres, Oracle, MySQL InnoDB) 의 default 보장이며, 2026 distributed era 에도 매 NewSQL (CockroachDB, Spanner, TiDB, Neon) 가 매 ACID across nodes 를 표방. 매 단일 transaction 이 매 multi-statement 의 all-or-nothing + isolated + persisted 를 보장.

## 매 핵심

### 매 4 properties
- **Atomicity**: 매 all statements commit or all rollback. 매 partial state 없음.
- **Consistency**: 매 transaction 종료 시 매 모든 invariant (FK, check, unique) 가 valid.
- **Isolation**: 매 concurrent transactions 가 매 serially executed 처럼 보임. 매 isolation level 로 trade-off.
- **Durability**: 매 commit 후 매 crash / power loss 에도 매 data 가 살아남음 (WAL → fsync).

### 매 Isolation levels (SQL standard + Postgres)
- **Read Uncommitted**: 매 dirty read 허용 (Postgres 는 사실상 RC 로 mapping).
- **Read Committed** (Postgres default): 매 dirty read X, 매 non-repeatable read O.
- **Repeatable Read** (Postgres = snapshot isolation): 매 phantom read 거의 없음, 매 serialization anomaly O.
- **Serializable** (Postgres = SSI): 매 strictest, 매 overhead 큼.

### 매 응용
1. 매 financial / inventory 의 multi-row update.
2. 매 idempotent worker — 매 transaction + unique key.
3. 매 saga compensation 의 단위.

## 💻 패턴

### 1) Postgres BEGIN/COMMIT
```sql
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  -- 매 atomic + durable
```

### 2) SAVEPOINT 로 partial rollback
```sql
BEGIN;
INSERT INTO orders(id, total) VALUES (1, 50);
SAVEPOINT before_items;
INSERT INTO items(order_id, sku) VALUES (1, 'BAD-SKU');  -- FK 위반
ROLLBACK TO SAVEPOINT before_items;
INSERT INTO items(order_id, sku) VALUES (1, 'OK');
COMMIT;
```

### 3) Isolation level 명시 (Python + asyncpg)
```python
async with conn.transaction(isolation="serializable"):
    row = await conn.fetchrow("SELECT balance FROM accounts WHERE id=$1", 1)
    await conn.execute("UPDATE accounts SET balance=$1 WHERE id=$2", row["balance"]-100, 1)
# 매 SSI — 매 serialization_failure 시 retry 필요
```

### 4) Optimistic concurrency (version column)
```sql
UPDATE doc SET body = $1, version = version + 1
WHERE id = $2 AND version = $3;
-- 매 affected_rows = 0 → conflict, 매 retry / 사용자 alert
```

### 5) SELECT FOR UPDATE (pessimistic lock)
```sql
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;  -- 매 row lock
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;
```

### 6) Outbox pattern (transaction + async publish)
```sql
BEGIN;
INSERT INTO orders(id, ...) VALUES (...);
INSERT INTO outbox(event_type, payload) VALUES ('OrderCreated', $1);
COMMIT;
-- 매 separate worker 가 outbox 를 읽고 매 broker 로 publish
```

### 7) Retry on serialization failure (Python)
```python
from psycopg.errors import SerializationFailure
for _ in range(5):
    try:
        with conn.transaction(): do_work()
        break
    except SerializationFailure:
        time.sleep(random.uniform(0, 0.05))
```

## 매 결정 기준
| 상황 | Isolation level |
|---|---|
| 매 read-heavy dashboard | Read Committed |
| 매 report 의 consistent snapshot | Repeatable Read |
| 매 money / counter / unique reservation | Serializable |
| 매 high-conflict hot row | Pessimistic FOR UPDATE |
| 매 low-conflict OLTP | Optimistic version |

**기본값**: Postgres Read Committed + 매 critical path 만 매 Serializable / FOR UPDATE.

## 🔗 Graph
- 변형: [[BASE]] · [[Snapshot Isolation]]
- 응용: [[Idempotency]]
- Adjacent: [[CAP Theorem & PACELC]]

## 🤖 LLM 활용
**언제**: 매 codegen 의 SQL transaction boundary 검증, 매 isolation level mismatch 점검.
**언제 X**: 매 eventually-consistent NoSQL (DynamoDB single-region) — 매 BASE 모델로 reasoning.

## ❌ 안티패턴
- **App-side "transaction"**: 매 read-modify-write 가 매 BEGIN/COMMIT 밖. 매 race condition.
- **Long transaction**: 매 minutes 단위 hold → 매 lock contention + bloat.
- **Wrong isolation**: 매 default RC 에서 매 lost update 발생, 매 detect 못 함.
- **Ignoring serialization failure**: 매 SSI 에서 매 retry 안 함 → 매 user-facing error.
- **Transaction across services**: 매 distributed XA 시도 → 매 saga 로 대체.

## 🧪 검증 / 중복
- Verified (Postgres 17 docs, Härder & Reuter 1983, Bailis "Highly Available Transactions" 2014).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — ACID + Postgres isolation levels + 7 patterns |