What Is a Transaction?
Before ACID, before SQL syntax, before Spring — you need the idea in your bones. This chapter builds it from a story you already understand: standing at a bank counter.
Learning objectives
- Explain what a transaction is in your own words, to a non-technical person.
- Give the beginner, technical, and interview-grade definitions of "transaction."
- Explain why simple CRUD operations aren't enough for real systems.
◆ Story
Imagine you walk into a bank and ask to transfer ₹10,000 from your Savings account to your friend's Current account. The bank clerk does two things: subtracts ₹10,000 from your account, then adds ₹10,000 to your friend's account. Now imagine the power goes out at the branch exactly between those two steps. ₹10,000 has vanished from your account. It never reached your friend. It simply doesn't exist anymore, anywhere. No bank on Earth can survive customers experiencing that, even occasionally — which is exactly why banks (and every serious database) guarantee that "subtract, then add" either happens completely, or not at all. There is no in-between state a customer can ever see.
That guarantee — "this group of steps either all happen, or none of them do" — is the entire idea of a transaction. Everything else in this book is refinement and implementation detail on top of that one sentence.
| Domain | The steps that must happen together | What "partial failure" would look like |
|---|---|---|
| ATM withdrawal | 1) Debit your account balance. 2) Dispense the cash. | Cash dispensed, but balance never debited — free money bug. Or balance debited, machine jams, no cash — you lose money. |
| Flight booking | 1) Reserve the seat. 2) Charge the payment. 3) Generate the ticket. | Seat reserved and payment charged, but ticket generation crashes — customer paid for a flight with no proof of booking. |
| Online shopping | 1) Reduce warehouse stock count. 2) Create the order record. 3) Charge the card. | Stock reduced and order created, but payment fails — a customer "has" an order they never paid for, and a unit of stock is now stuck reserved forever. |
| Food delivery | 1) Deduct wallet balance. 2) Notify the restaurant. 3) Assign a delivery partner. | Wallet deducted, but restaurant never notified — customer paid, and no food is ever coming. |
▲ Common mistake
Beginners often think a transaction is "a database query" or "an API call." It's neither — it's a grouping concept that can wrap one query or fifty. The number of individual operations is irrelevant; what matters is that the whole group is treated as one indivisible unit.
| Level | Definition |
|---|---|
| Beginner | A transaction is a group of steps that must all succeed together — like a bank transfer. If any step fails, the whole group is undone, as if nothing happened at all. |
| Technical | A transaction is a sequence of one or more database operations executed as a single logical unit of work, satisfying the ACID properties (Atomicity, Consistency, Isolation, Durability — Chapters 02–05), bounded by a BEGIN and either a COMMIT or a ROLLBACK. |
| Interview-grade | A transaction is the fundamental unit of consistency and recovery in a database system. It provides atomicity via undo/redo logging or MVCC, isolation via locking or snapshot isolation, and durability via write-ahead logging — allowing concurrent, failure-prone operations to appear, from the outside, as if they executed serially and instantaneously. |
◆ The problem
A beginner backend built with plain Create/Read/Update/Delete operations, each hitting the database independently, works perfectly in every demo — because demos don't have concurrent users, network blips, or crashes mid-request. The moment two real users act on the same data at the same time, or a server restarts mid-request, uncoordinated CRUD operations produce exactly the kind of partial, corrupted state the bank story above showed you must never allow.
Consider a warehouse system with no transaction boundary around "check stock, then decrement stock":
// Two customers click "Buy" on the LAST unit in stock, at almost the same instant int stock = productRepository.getStock(productId); // both threads read: stock = 1 if (stock > 0) { productRepository.decrementStock(productId); // BOTH threads pass this check orderService.createOrder(customerId, productId); // BOTH orders get created } // Result: 2 orders created for 1 unit of stock. Stock now shows -1.
Every mechanism in this entire book — locking, isolation levels, @Transactional, MVCC — exists to make scenarios like this one impossible, or at least detectable and controllable, rather than a silent production bug someone discovers three weeks later from a very angry customer.
💻 Code example
// Two customers click "Buy" on the LAST unit in stock, at almost the same instant int stock = productRepository.getStock(productId); // both threads read: stock = 1 if (stock > 0) { productRepository.decrementStock(productId); // BOTH threads pass this check orderService.createOrder(customerId, productId); // BOTH orders get created } // Result: 2 orders created for 1 unit of stock. Stock now shows -1.
Every transaction has exactly one of two possible endings. There is no third outcome — this binary nature is the single most important mental model in this entire book.
◆ Under the hood
While a transaction is "in progress" (between BEGIN and COMMIT / ROLLBACK), its changes exist in a working state the database tracks separately from the officially committed data — exactly how, mechanically, varies by engine (undo logs, MVCC row versions, write-ahead logs — all covered in later chapters), but the principle is universal: other transactions should not see your half-finished work, and if you fail partway through, the database must be able to cleanly discard everything you did and return to exactly the state before you began.
Beginner
Recognize a transaction anywhere you see "these steps must happen together, or not at all" — in code, in a diagram, or in a real-world process like a bank transfer.
Intermediate
Identify the correct transaction boundary in a piece of business logic — which operations belong inside it, and which (like sending a slow external email) probably shouldn't.
Advanced
Recognize when a "transaction" spans more than one database or service, and know (even before reading Chapters 15-19) that this is a fundamentally harder problem requiring different tools.
Want a visual for this concept?
Generate a diagram tailored to “What Is a Transaction?” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →