import { motion } from 'motion/react'; export default function ACIDTransactionsDiagram() { return (
TRANSACTIONS & ACID PROPERTIES
{/* Header */} Transaction: A sequence of database operations treated as a single logical unit of work. All operations must succeed together, or all must fail — enforced by ACID properties. {/* Lifecycle */} TRANSACTION LIFECYCLE {[ { x: 30, label: 'BEGIN', c: '#6366f1' }, { x: 195, label: 'ACTIVE', c: '#22c55e' }, { x: 360, label: 'PARTIALLY COMMITTED', c: '#3b82f6' }, { x: 560, label: 'COMMITTED', c: '#4ade80' }, ].map(({ x, label, c }, i) => ( {label} ))} FAILED → ROLLBACK {/* A — Atomicity */} A ATOMICITY "All or Nothing" Every op in a transaction succeeds, or the entire transaction is rolled back with no partial changes. Example: Bank Transfer ₹500 from A → B ✓ SUCCESS (COMMIT) 1. Debit A: -₹500 ✓ 2. Credit B: +₹500 ✓ Both written to disk A: ₹1000→₹500 B: ₹200→₹700 ✗ FAILURE (ROLLBACK) 1. Debit A: -₹500 ✓ 2. Credit B: ERROR ✗ Entire tx rolled back A stays ₹1000, B stays ₹200 Enforced by: Undo logs & Rollback mechanism Ops: COMMIT ROLLBACK {/* C — Consistency */} C CONSISTENCY "Valid State to Valid State" A transaction brings the DB from one valid state to another — all integrity constraints are preserved. Integrity Constraints that must hold: {[ { k: 'NOT NULL', v: 'Required fields must always have values', y: 0 }, { k: 'UNIQUE', v: 'No duplicates in constrained columns', y: 1 }, { k: 'CHECK', v: 'e.g. balance ≥ 0 — no negative balances', y: 2 }, { k: 'FOREIGN KEY', v: 'Referenced rows must exist in parent table', y: 3 }, { k: 'PRIMARY KEY', v: 'Must be unique and non-null', y: 4 }, ].map(({ k, v, y }) => ( {k} {v} ))} Violation → transaction aborted automatically. Consistency is the responsibility of both DB & application. {/* I — Isolation */} I ISOLATION "Transactions Don't Interfere" Concurrent transactions run as if they are serial. Intermediate states are hidden from other transactions. Isolation Levels (weakest → strongest): {[ { lv: 'READ UNCOMMITTED', note: 'Dirty Read allowed', c: '#f87171' }, { lv: 'READ COMMITTED', note: 'Prevents Dirty Read', c: '#fbbf24' }, { lv: 'REPEATABLE READ', note: 'Prevents Non-repeatable Read', c: '#60a5fa' }, { lv: 'SERIALIZABLE', note: 'Prevents Phantom Read — safest', c: '#4ade80' }, ].map(({ lv, note, c }, i) => ( {lv} {note} ))} Read Phenomena: • Dirty Read: sees uncommitted data of another tx • Non-repeatable Read: same query returns different rows • Phantom Read: new rows appear in a repeated range query Implemented via: Locks, MVCC (Multi-Version Concurrency Control) Higher isolation = more serializable but lower concurrency performance. Most DBs default to READ COMMITTED or REPEATABLE READ. PostgreSQL: defaults to READ COMMITTED | MySQL InnoDB: REPEATABLE READ {/* D — Durability */} D DURABILITY "Committed = Permanent" Once a transaction commits, changes persist forever — even across crashes, power failures, or errors. Techniques that ensure Durability: {[ { t: 'Write-Ahead Logging (WAL)', d: 'Log changes before applying to disk' }, { t: 'Checkpointing', d: 'Periodically flush dirty pages to storage' }, { t: 'Redo Logs', d: 'Replay committed txs after a crash' }, { t: 'Shadow Paging', d: 'Keep old page until commit is confirmed' }, ].map(({ t, d }, i) => ( ▸ {t} {d} ))} Crash Recovery Flow: {[ { label: 'CRASH', c: '#ef4444', x: 468 }, { label: 'READ REDO LOG', c: '#fbbf24', x: 560 }, { label: 'REPLAY COMMITS', c: '#3b82f6', x: 665 }, { label: 'DB RESTORED ✓', c: '#4ade80', x: 775 }, ].map(({ label, c, x }, i) => ( {label} {i < 3 && } ))} WAL ensures that crash recovery restores all committed changes. Committed transactions are ALWAYS recoverable. Used in: PostgreSQL (WAL), MySQL (InnoDB redo log), Oracle (REDO log files), SQL Server (Transaction Log) Storage media: SSDs and HDDs provide physical durability. For distributed systems: replication adds cross-node durability. Summary: ACID = the gold standard for reliable database transactions. ); }