Scaling data / Beginner / 5 min
Database transactions: commit, rollback, and pulling the plug
Crash the server mid-transfer. Without a transaction money vanishes; with one it rolls back. Then see why commits must reach the disk.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A transaction groups several database changes so they commit together or not at all, and a commit is kept even if the server crashes right after.
- Why it matters
- Money, stock and orders span several rows, and a crash between updates must never leave them half-done.
- The trade-off
- Waiting for the log to reach disk on every commit costs a few milliseconds; async commit is faster but can lose the last acknowledged writes.
- Say it in an interview
- "BEGIN; debit; credit; COMMIT with the WAL fsynced before OK (synchronous_commit on), idempotent retries, and replicas only for reads that can lag."
Check yourself
The server crashes after the debit and before the credit, with no transaction. What happens?
Answer: The debit is already saved, so the money is gone from both accounts. Each UPDATE committed on its own; nothing ties the two halves together.
What does atomicity (the A in ACID) guarantee?
Answer: All the updates in a transaction happen, or none of them do. On a crash, unfinished transactions are rolled back using the write-ahead log.
A database says OK before the commit is written to disk. What is the risk?
Answer: A crash can lose transfers the user was already told succeeded. Durability needs the log on disk (fsync) before acknowledging; async commit trades that for speed.