Imagine you are sending money to a friend using a mobile banking app. You type in the amount, tap “Send,” and within a second you see “Transaction Successful.” Behind that one tap, a database silently performed a small miracle: it took money out of your account and put it into your friend’s account, and it made sure that either both of those things happened, or neither of them happened. There was no moment where the money vanished from your account without appearing in your friend’s account.

That silent miracle has a name: a database transaction. It is one of the most important ideas in all of computer science, and yet most people who use apps every day have no idea it exists. This guide will take you from knowing nothing about transactions to understanding exactly how they work inside real databases like PostgreSQL, MySQL, Oracle, and distributed systems like Google Spanner.

1.1 A Short History

The idea of a transaction did not start with computers — it borrows its name and spirit from the world of business and banking, where a “transaction” simply means a completed exchange, like buying bread from a baker. Early computer scientists working on databases in the 1970s realised that computer systems needed the same guarantee that a business transaction has: it either fully happens, or it doesn’t happen at all — there is no “half a purchase.”

The formal theory of transactions was shaped heavily by Jim Gray, a computer scientist at IBM, who in the 1970s and 1980s developed much of the mathematical foundation for what we now call transaction processing. His work, along with research from IBM’s System R project (one of the first relational database prototypes) and later work at IBM, Oracle, and academic institutions, gave us the term ACID — a set of four guarantees that every serious database tries to provide. We will explore ACID in deep detail in Section 4.

By the 1980s and 1990s, transactions became a standard feature of relational databases like Oracle, IBM DB2, Microsoft SQL Server, and later open‑source databases like PostgreSQL and MySQL. Today, even many “NoSQL” databases that originally skipped transactions (to gain speed) — such as MongoDB and Google Cloud Spanner — have added transaction support back in, because developers found it too hard and too risky to build reliable applications without them.

1.2 A Quick Timeline

• 1970sIBM’s System R project pioneers relational databases; Jim Gray develops much of the theoretical foundation of transaction processing.
• 1981The term ACID is popularised in academic literature, capturing the four guarantees serious transactional systems aim for.
• 1980s–1990sTransactions become a standard feature of Oracle, IBM DB2, Microsoft SQL Server, and other commercial relational databases.
• 1990s–2000sPostgreSQL and MySQL bring solid transactional support to the open‑source world.
• 2000s–2010sEarly NoSQL systems trade transactions for scale; developers quickly discover the operational pain of that trade.
• 2012‑presentGoogle Spanner, CockroachDB, YugabyteDB, and other distributed SQL systems bring globally‑consistent ACID transactions back at planetary scale.

To understand why we need transactions, let’s imagine a world without them. Suppose you run an online bookstore. A customer, Riya, buys a book for ₹500. To complete this “purchase,” your application needs to do three separate things in the database:

1. Reduce the book’s stock count by 1.
2. Insert a new row into the “orders” table.
3. Deduct ₹500 from Riya’s wallet balance.

Without transactions, these are three independent database operations. Now imagine the server crashes, or the network drops, right after step 2 but before step 3. What happens? The order exists in your system, the stock has been reduced — but Riya’s wallet was never charged. She got a free book. Or worse: imagine the crash happens between step 3 and step 2 — she got charged, but no order was created and the stock was never reduced. She paid for nothing.

2.1 The Core Problems Transactions Solve

The solution computer scientists arrived at is elegant: group related operations into a single logical unit called a transaction, and let the database guarantee that this unit behaves like one atomic (indivisible) step — even though it is really made up of multiple smaller steps internally.

A database transaction is a sequence of one or more database operations (reads and writes) that are treated as a single, indivisible unit of work. Either all the operations inside the transaction succeed and are permanently saved, or none of them are — the database is left exactly as if the transaction never started.

“A transaction is the database’s way of saying: ‘Trust me, I will either finish this job completely, or I will act as if I never touched anything.’”

3.1 Where Transactions Are Used

• Banking systems: money transfers, EMI deductions, interest calculations.
• E‑commerce: checkout flows, inventory deduction, order creation, coupon redemption.
• Airline & ride booking: seat reservation, ride matching, fare deduction.
• Social media: posting content plus updating counters (likes, follower counts) together.
• Inventory & warehouse systems: stock movement between warehouses.
• Multiplayer games: trading items between two players’ inventories.

3.2 A Transaction Is Defined by Statements, Not Just SQL

In SQL databases, a transaction is usually written using three key commands:

BEGIN;  -- or START TRANSACTION;

UPDATE accounts SET balance = balance - 500 WHERE id = 'riya';
UPDATE accounts SET balance = balance + 500 WHERE id = 'store';
INSERT INTO orders (customer_id, amount) VALUES ('riya', 500);

COMMIT;  -- save everything permanently
-- OR
ROLLBACK; -- undo everything if something went wrong

BEGIN tells the database: “Everything from here onward is one group — don’t finalise anything until I say so.” COMMIT tells the database: “I’m done, and everything worked — please save it all permanently.” ROLLBACK tells the database: “Something went wrong — please undo everything back to how it was before BEGIN.”

3.3 Key Terms You Must Know

ACID is an acronym that describes the four guarantees a properly implemented transaction provides: Atomicity, Consistency, Isolation, Durability. Let’s go through each one slowly, because interview questions about databases almost always start here.

Fig 4.1 — The four ACID properties, each protecting against a different kind of failure.

4.1 A — Atomicity: All or Nothing

What it is: atomicity guarantees that a transaction is treated as a single indivisible unit. If any part of it fails, the entire transaction fails, and the database rolls back to its state before the transaction began.

Why it exists: without atomicity, a crash halfway through a multi‑step operation leaves the database in a broken, half‑done state — like Riya’s book‑order example from Section 2.

4.2 C — Consistency: Valid State to Valid State

What it is: consistency means a transaction can only bring the database from one valid state to another valid state, respecting all defined rules — such as constraints, foreign keys, unique indexes, and triggers. A transaction that would break these rules is rejected entirely.

Why it exists: every real‑world system has rules that must never be violated — for example, “account balance cannot go below zero” or “a seat cannot be assigned to two passengers.” Consistency ensures the database enforces these rules on every single transaction.

4.3 I — Isolation: Transactions Don’t Step on Each Other

What it is: isolation ensures that concurrently running transactions do not interfere with each other. Even though many transactions may run at the exact same time, each one should behave as though it is running alone.

Why it exists: real systems have thousands of transactions happening every second. Without isolation, one transaction could read another’s half‑finished, uncommitted changes, leading to wrong results (we cover this in depth in Section 7).

4.4 D — Durability: Once Saved, Always Saved

What it is: durability guarantees that once a transaction is committed, its changes are permanent — they will survive even a power failure, crash, or system restart.

Why it exists: imagine your bank confirms a deposit, but the server crashes 1 second later and the deposit disappears. That would destroy all trust in the system. Durability is the database’s promise that “committed means committed, forever.”

4.5 ACID at a Glance

Every transaction moves through a well‑defined set of states from the moment it begins to the moment it finishes. Understanding this lifecycle helps you reason about what can go wrong and when.

Fig 5.1 — The transaction lifecycle — from Active, through either success (Committed) or failure (Aborted).

5.1 The States Explained

• Active: the transaction has started (BEGIN) and is executing its statements (reads and writes).
• Partially Committed: the final statement has executed, but the database hasn’t yet permanently written the results to disk.
• Committed: all changes are permanently saved. This is the successful end state.
• Failed: something went wrong (a constraint violation, a crash, a deadlock) during execution.
• Aborted: the database has rolled back all changes made by the failed transaction, restoring the previous state.

Now let’s go deeper. How does a database actually guarantee atomicity and durability internally? The answer, for almost every relational database, is a mechanism called the Write‑Ahead Log (WAL), sometimes called the transaction log or redo log.

6.1 Write‑Ahead Logging (WAL)

What it is: WAL is a rule that says: before any change is made to the actual data files on disk, the database must first write a record describing that change to an append‑only log file, and that log record must be safely flushed to disk.

Why it exists: updating actual data pages on disk is slow and complex (data pages are scattered across the disk). But writing a simple sequential log entry is fast. WAL lets the database confirm “this change is durable” quickly by writing to the log, while the slower job of updating the real data pages happens later, in the background.

Fig 6.1 — Write‑ahead logging — the log is written and confirmed before (and faster than) the actual data pages are updated.

6.2 Undo Logs and Redo Logs

Databases like MySQL’s InnoDB engine and Oracle use two complementary logs:

6.3 Crash Recovery

When a database restarts after a crash, it runs a recovery process (often called ARIES in academic literature, used conceptually by most modern databases) with three phases:

1. Analysis: scan the log to find out which transactions were active at the time of the crash.
2. Redo: reapply all logged changes, even for committed transactions, to bring data pages up to date (because writes to disk may not have completed before the crash).
3. Undo: roll back any transactions that were never committed, using the undo log, so the database ends up in a clean, consistent state.

Isolation sounds simple in theory (“transactions shouldn’t interfere with each other”), but in practice, perfect isolation is expensive — it can make a database slow, because it means transactions often have to wait for each other. So database designers created several isolation levels, each offering a different trade‑off between correctness and performance.

7.1 The Anomalies Isolation Levels Prevent

Before understanding the levels, you need to understand the problems (called “anomalies”) that can happen when isolation is weak:

7.2 The Four Standard Isolation Levels (SQL Standard)

*Note: MySQL InnoDB’s Repeatable Read actually prevents most phantom reads too, thanks to its MVCC + gap locking implementation — this is a well‑known deviation from the strict SQL standard definition.

7.3 Serializable: The Strongest Guarantee

What it is: Serializable isolation guarantees that the result of running multiple transactions concurrently is identical to some order of running them one after another (serially), even though they actually overlapped in time.

Why it exists: this is the safest possible guarantee — but it comes at a real performance cost, because the database might need to detect conflicts and force one transaction to retry.

One classic way databases achieve isolation is through locks — a mechanism that controls which transactions are allowed to read or write a piece of data at any given moment.

8.1 Shared Locks vs. Exclusive Locks

8.2 Two‑Phase Locking (2PL)

What it is: Two‑Phase Locking is a protocol where a transaction acquires all the locks it needs during a “growing phase,” and only starts releasing locks during a “shrinking phase” — once it starts releasing locks, it is not allowed to acquire any new ones.

Why it exists: this simple rule mathematically guarantees serialisability — it prevents certain classes of conflicts from ever corrupting the data.

8.3 Deadlocks

What it is: a deadlock happens when two (or more) transactions are each waiting for a lock the other one is holding, so neither can ever proceed.

Fig 8.1 — A classic deadlock — Transaction A wants what B holds, and B wants what A holds. Neither can proceed.

How databases resolve deadlocks: almost every production database runs a background deadlock detector. It periodically looks for cycles in a “wait‑for graph” (which transaction is waiting for which). When it finds a cycle, it picks one transaction as the “victim,” forcibly rolls it back, and lets the other proceed. The application is expected to catch this error and retry the transaction.

Locking works, but it has a downside: readers can block writers, and writers can block readers, hurting performance under heavy concurrent load. Modern databases like PostgreSQL, MySQL InnoDB, and Oracle solve this using a smarter approach called MVCC (Multi‑Version Concurrency Control).

What it is: instead of locking a row every time someone reads it, the database keeps multiple “versions” of each row. When a transaction updates a row, the database doesn’t overwrite the old data immediately — it creates a new version while keeping the old version around for any transactions that might still need to see it.

Why it exists: MVCC allows readers to never block writers, and writers to never block readers. A read simply looks at the version of the data that was valid when its transaction started, while writers can create new versions in parallel.

9.1 How MVCC Works Internally

• Every row gets hidden metadata: which transaction created it, and (if deleted/updated) which transaction removed it.
• Each transaction gets a unique, increasing transaction ID (or a timestamp/snapshot).
• When reading, a transaction only “sees” row versions that were committed before its own snapshot began, and ignores versions created by transactions that started later or haven’t committed.
• Old, no‑longer‑needed row versions are eventually cleaned up by a background process — in PostgreSQL this is called VACUUM.

Everything so far assumed a transaction lives inside one single database. But modern systems are often split across many databases or microservices — for example, an “order service” and a “payment service” might each have their own separate database. How do you get ACID‑like guarantees across multiple, independent systems?

10.1 Two‑Phase Commit (2PC)

What it is: 2PC is a protocol that coordinates a transaction across multiple databases (called “participants”) using a central coordinator, in two phases: a “prepare” phase, and a “commit” phase.

Fig 10.1 — Two‑Phase Commit — the coordinator asks all participants to “prepare,” and only commits everywhere if all say yes.

1. Phase 1 (Prepare): the coordinator asks every participant database, “Can you guarantee you’ll be able to commit this?” Each participant locks its resources, writes to its own log, and replies “yes” or “no,” without actually committing yet.
2. Phase 2 (Commit/Abort): if every participant said “yes,” the coordinator tells everyone to commit for real. If even one said “no” (or timed out), the coordinator tells everyone to abort.

10.2 The Saga Pattern

What it is: instead of one giant distributed transaction, a Saga breaks a business process into a sequence of smaller, local transactions, each in its own service. If a later step fails, the Saga executes compensating actions — essentially “undo” operations — for the steps that already succeeded.

10.3 CAP Theorem and Transactions

What it is: the CAP theorem states that a distributed system can only guarantee two out of three properties at the same time: Consistency (every read gets the latest write), Availability (every request gets a response), and Partition Tolerance (the system keeps working despite network failures between nodes).

Since network partitions are unavoidable in real distributed systems, the real‑world choice is between Consistency and Availability during a partition. Systems that prioritise strong consistency for transactions (like Google Spanner, using a special globally synchronised clock system called TrueTime) sacrifice some availability during network issues, while systems that prioritise availability (like many NoSQL databases) may serve slightly stale data during a partition.

Let’s see how transactions look in real Java code, using plain JDBC first, then Spring’s higher‑level abstraction, and finally the deadlock‑retry idiom you’ll want in production.

11.1 Plain JDBC Transaction

Connection conn = null;
try {
    conn = dataSource.getConnection();
    conn.setAutoCommit(false); // start the "transaction mode"

    PreparedStatement debit = conn.prepareStatement(
        "UPDATE accounts SET balance = balance - ? WHERE id = ?");
    debit.setBigDecimal(1, amount);
    debit.setString(2, fromAccountId);
    debit.executeUpdate();

    PreparedStatement credit = conn.prepareStatement(
        "UPDATE accounts SET balance = balance + ? WHERE id = ?");
    credit.setBigDecimal(1, amount);
    credit.setString(2, toAccountId);
    credit.executeUpdate();

    conn.commit(); // save both changes permanently
} catch (SQLException e) {
    if (conn != null) conn.rollback(); // undo everything
    throw new RuntimeException("Transfer failed, rolled back", e);
} finally {
    if (conn != null) conn.setAutoCommit(true);
    if (conn != null) conn.close();
}

Here, setAutoCommit(false) tells JDBC “don’t save every single statement automatically — wait for my explicit signal.” commit() finalises both updates together; rollback() undoes both if any exception occurs.

11.2 Spring Framework: @Transactional

Manually managing connections and rollback logic in every method is repetitive and error‑prone. Spring Framework provides the @Transactional annotation, which wraps a method in transaction boundaries automatically.

@Service
public class TransferService {

    private final AccountRepository accountRepository;

    public TransferService(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }

    @Transactional(isolation = Isolation.READ_COMMITTED,
                   rollbackFor = InsufficientFundsException.class)
    public void transfer(String fromId, String toId, BigDecimal amount) {
        Account from = accountRepository.findById(fromId)
            .orElseThrow(() -> new AccountNotFoundException(fromId));
        Account to = accountRepository.findById(toId)
            .orElseThrow(() -> new AccountNotFoundException(toId));

        if (from.getBalance().compareTo(amount) < 0) {
            throw new InsufficientFundsException(fromId);
        }

        from.setBalance(from.getBalance().subtract(amount));
        to.setBalance(to.getBalance().add(amount));

        accountRepository.save(from);
        accountRepository.save(to);
        // Spring commits automatically here if no exception was thrown
    }
}

Spring uses an underlying proxy that starts a transaction before the method runs, and commits it after the method returns successfully — or rolls it back automatically if a RuntimeException (or any exception you explicitly configure with rollbackFor) is thrown.

11.3 Handling Deadlock Retries in Java

int attempts = 0;
while (attempts < 3) {
    try {
        transferService.transfer(fromId, toId, amount);
        break; // success
    } catch (DeadlockLoserDataAccessException e) {
        attempts++;
        if (attempts == 3) throw e;
        Thread.sleep(50L * attempts); // simple backoff
    }
}

Because the database’s deadlock detector may pick your transaction as the “victim” and force a rollback (see Section 8), well‑designed applications retry the operation a small number of times with a short backoff delay, rather than failing the user’s request immediately.

Every architectural choice is a trade‑off. Transactions buy correctness and simplicity — but in exchange, they cost performance, add complexity in distributed settings, and require careful design.

12.1 The Fundamental Trade-off: Safety vs. Speed

Every isolation level, every locking strategy, and every distributed‑transaction protocol is a trade‑off between how correct the guarantee is and how much it costs in terms of speed and complexity. This is one of the most important intuitions to build as an architect: there is no free lunch — stronger guarantees always cost something, whether it’s latency, throughput, or engineering complexity.

Transactions, if used carelessly, are one of the most common sources of performance problems in production systems. Here are the key levers architects and engineers use to keep transactional systems fast at scale.

13.1 Keep Transactions Short

The longer a transaction stays open, the longer it holds locks (or, under MVCC, the longer it prevents old row versions from being cleaned up). Long transactions increase contention and can cause other transactions to wait or fail.

13.2 Batching

Instead of committing one row at a time (which forces a disk flush per commit), batching groups multiple inserts/updates into fewer transactions, dramatically reducing overhead — especially useful for bulk data loading.

13.3 Connection Pooling

Opening a new database connection is expensive. Connection pools (like HikariCP in the Java ecosystem) keep a set of ready‑to‑use connections open, so transactions can start instantly instead of paying connection setup costs every time.

13.4 Read Replicas for Read‑Heavy Workloads

Many systems separate “read” traffic from “write” traffic, sending reads that don’t need the absolute latest data to replica databases, while all writes (which need strong transactional guarantees) go to the primary database. This reduces load on the primary and improves overall throughput.

13.5 Sharding / Partitioning

At very large scale, a single database server cannot handle all the transaction load. Sharding splits data across multiple database servers (for example, by customer region or user ID range), so transactions on different shards can run fully in parallel, with no contention between them — at the cost of making cross‑shard transactions much harder (this is exactly the problem 2PC and Sagas try to solve).

A transactional guarantee is only as good as the system’s ability to survive failure. Two key techniques make transactional databases highly available:

14.1 Replication

What it is: replication keeps copies of the same data on multiple servers. If the primary server fails, a replica can be promoted to take over, minimising downtime.

• Synchronous replication: a transaction isn’t considered committed until at least one replica confirms it has the data too. Safer (no data loss on failover), but slower.
• Asynchronous replication: the primary commits immediately and sends changes to replicas afterward. Faster, but a crash right after commit could lose the last few transactions that hadn’t reached the replica yet.

14.2 Backup and Point‑in‑Time Recovery

Because the transaction log (WAL) contains a complete, ordered history of every change, databases can restore a backup and then “replay” the log up to any exact point in time — extremely useful for recovering from accidental data corruption, like an engineer’s mistaken bulk delete.

14.3 Disaster Recovery

Beyond a single data centre failing, well‑run systems plan for entire regions going offline. This typically means maintaining replicas in geographically distant data centres, along with clear, tested failover procedures and a defined RPO (Recovery Point Objective — how much data loss is acceptable) and RTO (Recovery Time Objective — how much downtime is acceptable).

Transactions are about correctness, not access control — but the two intersect at critical points, and getting either one wrong can be catastrophic.

15.1 SQL Injection and Transactions

Transactions don’t protect against SQL injection — that’s a separate concern solved by using parameterised queries (as shown in the JDBC example in Section 11, using PreparedStatement). However, a poorly secured transaction that allows arbitrary SQL injection can be devastating, since an attacker could manipulate multiple related statements within the same transactional context.

15.2 Least‑Privilege Database Accounts

Application accounts used to run transactions should have the minimum permissions necessary. An application account that only needs to read and write specific tables should never have permission to drop tables or alter schemas — this limits the damage from a compromised application.

15.3 Auditing Transactional Changes

Sensitive systems (like banking or healthcare) often maintain an audit log — a separate, often append‑only, record of who changed what and when, distinct from the database’s internal WAL. This is important both for security investigations and for regulatory compliance (such as financial regulations requiring a full audit trail).

15.4 Encryption

Data written during a transaction — both the actual data files and the transaction log itself — should be encrypted at rest, and connections carrying transactional traffic should use TLS encryption in transit, so that a compromised disk or intercepted network packet doesn’t expose sensitive information like account balances or personal data.

In production, you can’t just “hope” transactions are working well — you need visibility. Here are the metrics that matter most for transactional health.

16.1 Distributed Tracing

In microservice architectures using Sagas, tools like OpenTelemetry, Jaeger, or Zipkin let engineers trace a single business transaction (e.g. “place order”) as it flows across multiple services and their individual local transactions, making it possible to see exactly where in a multi‑step saga something failed.

Modern cloud platforms have made deploying transactional databases significantly easier, while also introducing new distributed‑transaction‑friendly options.

17.1 Managed Relational Databases

Services like Amazon RDS, Google Cloud SQL, and Azure Database handle patching, backups, replication, and failover automatically for traditional transactional databases (PostgreSQL, MySQL, SQL Server), while still exposing full ACID transaction support to the application.

17.2 Distributed SQL Databases

A newer category of databases — Google Cloud Spanner, CockroachDB, and YugabyteDB — combine the horizontal scalability of NoSQL systems with full ACID transaction guarantees across many machines and even multiple regions, using consensus algorithms (commonly Raft or Paxos) to keep replicas agreeing on the true state of the data.

17.3 Containers and Kubernetes

When databases run in containers (via Kubernetes StatefulSets, for example), special care is needed for transactional systems: persistent storage volumes must survive pod restarts, and failover automation must ensure only one instance believes it is the “primary” at any time (avoiding a dangerous “split‑brain” scenario where two nodes both accept writes independently).

17.4 Cost Optimisation

Transactional workloads often dictate database sizing (CPU, memory, IOPS) more than raw data volume does, because heavy write/lock contention needs more compute headroom. Common cost levers include right‑sizing instances based on actual transaction throughput, using read replicas to offload read traffic from the more expensive primary instance, and archiving old transactional data to cheaper storage once it’s no longer actively updated.

A small number of named patterns keep showing up around transactions because they answer recurring problems well. An equally small number of anti‑patterns keep showing up because they’re the shortcuts everyone is tempted to take.

18.1 Unit of Work Pattern

What it is: a design pattern where all the changes to be made during a business operation are collected in memory first, and then submitted to the database as a single transaction at the end — rather than issuing separate database calls scattered across the code.

18.2 Outbox Pattern

What it is: a pattern for reliably publishing events alongside a database transaction. Instead of writing to the database and separately publishing a message to a queue (which can fail independently, causing inconsistency), the event is written to an “outbox” table as part of the same local transaction. A separate background process then reliably publishes it to the message queue.

18.3 Common Anti-patterns

The gap between a healthy transactional system and a fragile, deadlock‑ridden one is usually not a technology gap — it’s a discipline gap. These are the habits successful teams share.

19.1 Best Practices

• 01Keep transactions as short as possible. Do all slow work (API calls, file I/O, heavy computation) outside the transaction boundary.
• 02Choose the weakest isolation level that is still safe for your use case — don’t default to Serializable everywhere; it’s often unnecessary and costly.
• 03Always handle rollback and retry logic explicitly for deadlocks and transient failures, rather than assuming every transaction will succeed on the first try.
• 04Update related rows in a consistent order across your entire codebase to minimise deadlocks.
• 05Use connection pooling and avoid opening a fresh raw connection for every transaction.
• 06Avoid distributed transactions where possible. Prefer Sagas or the Outbox pattern over 2PC when working across microservices.
• 07Never let a transaction span a user’s “think time” (e.g., don’t open a transaction, wait for a user to click a button, then commit).
• 08Set sensible transaction timeouts so a stuck transaction doesn’t hold resources indefinitely.
• 09Monitor deadlocks, rollback rates, and lock wait times as first‑class production metrics, not an afterthought.
• 10Test failure scenarios deliberately — simulate crashes mid‑transaction in staging environments to confirm your rollback and recovery logic actually works.

19.2 Common Mistakes and Their Fixes

Almost every recognisable digital experience is quietly powered by transactions somewhere in the stack. Here’s a short tour of how large systems apply them at scale.

A short set of the questions engineers, students, and interviewers ask most about database transactions.

This is a technical, educational topic and does not involve any sensitive personal or safety concerns.

A database transaction is the fundamental building block that lets applications treat multiple related database operations as one safe, indivisible unit — a promise that either everything happens, or nothing does. This one idea, formalised through the ACID properties, quietly protects nearly every digital interaction you have, from a bank transfer to an online purchase to booking a ride.

Key Takeaways

• 01Atomicity, Consistency, Isolation, and Durability are the four guarantees every serious transactional database strives to provide.
• 02Internally, databases achieve these guarantees using write‑ahead logs, locks, and modern techniques like MVCC.
• 03Isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) let you trade off correctness against performance based on your specific needs.
• 04Deadlocks are a normal, expected part of concurrent systems — databases detect and resolve them automatically, and well‑designed applications retry gracefully.
• 05Across microservices, 2PC and the Saga pattern offer two very different philosophies for coordinating transactions spanning multiple independent systems.
• 06Real production systems — from Amazon to Uber to Netflix to Google Spanner — make deliberate, thoughtful trade‑offs about where strict transactional guarantees are worth the cost, and where eventual consistency is good enough.
• 07Mastering transactions means mastering trade‑offs: every extra bit of safety costs something in speed or complexity, and a good engineer knows exactly when that cost is worth paying.

“A transaction is a small, quiet promise between the database and the world: either everything happened, or nothing did — and you can always trust the answer.”