ACID is a set of four guarantees that every serious database quietly makes with your application — and understanding those four letters is the single biggest step from writing hobby code to shipping systems people can trust with their money.

Imagine you are sending ₹5,000 to your friend using a mobile banking app. Money leaves your account. A second later, it appears in your friend’s account. You don’t think twice about it — it just works.

But behind that simple tap, a database had to make a very serious promise: either the entire transfer happens, or none of it happens. Your money can never vanish into thin air. It can never be deducted from your account without appearing in your friend’s account, even if the bank’s server crashes at the worst possible millisecond.

That promise has a name. It is called ACID, and it stands for:

ACID is not a product, a library, or a specific piece of software. It is a set of guarantees — a contract — that a database system makes with every application that uses it. Relational databases like PostgreSQL, MySQL, Oracle, and SQL Server are built around this contract. Understanding ACID is one of the most important milestones in becoming a competent backend engineer, because almost every serious system — banking, e‑commerce, ticket booking, inventory, payroll — depends on it.

By the end of this tutorial, you will understand not just what each letter stands for, but exactly how databases implement these guarantees internally, what trade‑offs they involve, how they behave in distributed and cloud‑native systems, and how to use them correctly in real Java applications.

ACID is not a modern invention — it is the crystallised wisdom of half a century of database research. Knowing where it came from makes the guarantees themselves easier to trust.

The term ACID was coined in 1983 by computer scientist Theo Härder and database pioneer Andreas Reuter in a paper about achieving robustness in database systems. However, the ideas behind ACID existed much earlier — they trace back to work in the 1970s at IBM, particularly through the System R project, which was one of the first implementations of a relational database following Edgar F. Codd’s relational model (published in 1970).

Before ACID was formally named, engineers already understood that computers could fail mid‑operation — power could go out, a program could crash, a network cable could be unplugged. The question was: how do you build a system that behaves predictably even when the underlying hardware and software are unreliable? The answer that emerged was the concept of a transaction — a unit of work that is guaranteed to either complete fully or not happen at all.

This history matters because it shows ACID is not an outdated academic idea — it is a living, evolving engineering discipline. What started as a way to protect a single mainframe from crashing mid‑update has grown into the backbone of globally distributed financial systems processing millions of transactions per second.

To understand why ACID exists, imagine a world without it. Let’s walk through what could go wrong — and how quickly wrong turns into catastrophic when real money is at stake.

3.1 Scenario: a bank transfer without ACID

Suppose transferring ₹1,000 from Account A to Account B requires two separate database operations:

1. Subtract ₹1,000 from Account A.
2. Add ₹1,000 to Account B.

Now imagine the server crashes right after step 1 but before step 2. Without any protective mechanism, ₹1,000 has simply disappeared. Account A lost money, and Account B never received it. This is called a partial update, and it is one of the most dangerous failure modes in software.

These aren’t hypothetical. Early computing systems, and even poorly designed modern systems, suffer from exactly these bugs. ACID exists because engineers needed a formal, provable way to guarantee that none of these failure modes could happen — regardless of crashes, concurrent users, or hardware failures.

3.2 Scenario: two customers, one seat

Consider a train booking system with exactly one seat remaining. Two customers, Priya and Rahul, both click “Book” within the same fraction of a second. Both requests check the database and see “1 seat available.” Both proceed to book it. Without proper isolation, the database might process both bookings successfully, leaving two confirmed tickets for a single physical seat — a real, well‑documented category of bug that has genuinely affected ticketing systems around the world during high‑demand sales. ACID’s isolation guarantee is specifically designed to make this scenario impossible: the database ensures only one of the two transactions can “win” the last seat, and the other is correctly told the seat is no longer available.

Let’s slow down and go through each letter in depth. Each one solves a specific, distinct problem — and understanding each in isolation is the fastest path to understanding how the four work together.

4.1 A — Atomicity

What it is: Atomicity means a transaction is treated as a single, indivisible unit. “Atomic” comes from the Greek word for “indivisible.” Either every operation inside the transaction succeeds, or none of them do — the database is rolled back to exactly how it was before the transaction started.

Why it exists: Real‑world operations are rarely a single database write. A bank transfer needs two writes. Placing an order needs to reduce stock, create an order record, and charge a payment — three or more writes. If your program or server crashes halfway, you don’t want half the writes applied.

Where it’s used: Payments, order processing, inventory management, multi‑step form submissions — any operation with more than one write.

It’s worth understanding why atomicity is hard to get right without database support. If you tried to implement it yourself in application code, you would need to manually track every change you made, and manually write code to reverse each one if a later step failed — and you would need to get this perfectly right for every possible failure point, including the process crashing while your own “undo” code is running. The database solves this once, generically, for every transaction, so you never have to reinvent it.

4.2 C — Consistency

What it is: Consistency means every transaction takes the database from one valid state to another valid state, according to all defined rules: constraints, triggers, cascades, and data types. A transaction that would break a rule is rejected entirely.

Why it exists: Databases enforce business rules — for example, “an account balance can never go below zero,” or “every order must reference a real customer.” Without consistency, buggy application code could silently corrupt data in ways that violate these fundamental rules.

Where it’s used: Foreign key constraints, check constraints, unique constraints, and any business rule encoded directly into the database schema.

4.3 I — Isolation

What it is: Isolation ensures that transactions running at the same time do not see each other’s incomplete, in‑progress changes. Each transaction behaves as if it were the only one running, even though many may be executing concurrently for performance reasons.

Why it exists: Real applications serve thousands of users simultaneously. Without isolation, two people editing the same bank account, or booking the same concert seat, could interfere with each other in unpredictable and dangerous ways.

Where it’s used: Ticket booking systems, stock trading platforms, e‑commerce checkouts, ride‑hailing driver assignment — anywhere multiple users compete for the same resource.

We’ll explore isolation in much greater depth in the dedicated section below, because it has multiple “levels,” each with different trade‑offs.

4.4 D — Durability

What it is: Durability guarantees that once a transaction has been confirmed (committed), its effects are permanent — they will survive a crash, power failure, or restart of the database server.

Why it exists: Users trust that once they see “Payment Successful,” that fact is permanently recorded. If the server crashed one second later and the payment record vanished, trust in the entire system would collapse.

Where it’s used: Every “successful” confirmation message you’ve ever seen — order confirmations, payment receipts, saved documents, sent messages.

Together, these four properties don’t operate independently — they reinforce each other. Atomicity depends on durability to make its “commit” decision permanent. Isolation depends on atomicity to ensure a transaction’s partial work never becomes visible to others. Consistency depends on all three of the others working correctly to guarantee that only valid states are ever observed. This is why ACID is discussed as a single, unified contract rather than four separate features you can pick and choose from.

ACID isn’t magic — it’s implemented through specific, well‑engineered components inside every relational database engine. Let’s look at the major building blocks.

5.1 Transaction Manager

This component tracks the lifecycle of every transaction: BEGIN, COMMIT, or ROLLBACK. It coordinates with the lock manager and the logging system to make sure atomicity and isolation rules are enforced.

5.2 Lock Manager

Responsible for controlling which transactions can read or write which rows/pages at a given time, preventing conflicting concurrent access. Uses locks like shared locks (for reads) and exclusive locks (for writes).

5.3 Write-Ahead Log (WAL)

Also called the “redo log” or “transaction log.” Before any change is applied to the actual data files, it is first written to this append‑only log on disk. This is the backbone of durability and crash recovery.

5.4 Buffer Pool / Page Cache

Databases don’t read and write directly to disk for every operation — that would be far too slow. Instead, data pages are loaded into an in‑memory buffer pool, modified there, and eventually “flushed” to disk. The WAL ensures that even if a crash happens before a flush, no committed data is lost.

5.5 Concurrency Control Engine

Implements the actual isolation strategy — typically either Two‑Phase Locking (2PL) or Multi‑Version Concurrency Control (MVCC). We’ll explain both in detail in the next section.

5.6 Recovery Manager

Runs when the database restarts after a crash. It reads the WAL and “replays” any committed transactions that weren’t yet flushed to disk (redo), and undoes any transactions that were in‑progress but never committed (undo).

These six components don’t operate in isolation from one another — they form a tightly coordinated pipeline. A single UPDATE statement inside a transaction might trigger the lock manager to acquire a row lock, the transaction manager to record an undo entry, the WAL to append a log record, and the buffer pool to mark a page as “dirty” for later flushing — all within microseconds, and all designed so that no matter where a crash occurs in that pipeline, the system can recover to a correct, well‑defined state.

Now let’s go one level deeper and understand the actual mechanics — the algorithms and data structures that turn these architectural components into working guarantees.

6.1 How atomicity is implemented — undo logging

When a transaction modifies data, the database first records the old value in an undo log before overwriting it. If the transaction fails or is rolled back, the database reads the undo log backward and restores every old value — as if the transaction never happened.

6.2 How durability is implemented — Write-Ahead Logging (WAL)

The golden rule of WAL is: never write a data change to the actual database file until the log entry describing that change has been safely written to disk first. This is what allows crash recovery to work reliably.

1. 1. Transaction wants to change a row.

   The engine identifies the affected row and computes the new value.

2. 2. Log record is appended to WAL.

   Something like “Change balance of Account 42 from 500 to 300” is appended to the WAL file in memory.

3. 3. WAL is flushed to physical disk (fsync).

   The WAL buffer is forced to persistent storage using an fsync system call.

4. 4. Only then is COMMIT reported successful.

   The application receives its success acknowledgment only after the WAL flush is durable.

5. 5. Data page is updated lazily.

   The buffer pool marks the page dirty and flushes it to disk later — because if a crash happens, the WAL has everything needed to redo it.

6.3 How isolation is implemented — 2PL and MVCC

Two‑Phase Locking (2PL): A transaction acquires locks on the rows it touches as it goes (growing phase), and releases all locks only after commit or rollback (shrinking phase). This guarantees isolation but can cause transactions to wait for each other, and even deadlocks (two transactions each waiting for a lock the other holds).

Multi‑Version Concurrency Control (MVCC): Instead of blocking readers with locks, the database keeps multiple versions of each row. A transaction reads the version of the data that was valid when it started, while writers create new versions. Readers never block writers, and writers never block readers. PostgreSQL, MySQL’s InnoDB, and Oracle all use MVCC as their primary mechanism for read consistency.

6.4 How consistency is implemented

Consistency is enforced through a combination of: schema constraints (NOT NULL, CHECK, UNIQUE, FOREIGN KEY), triggers, and the atomicity/isolation machinery working together. If any constraint is violated mid‑transaction, the database automatically triggers a rollback using the undo log described above.

6.5 Deadlock detection

Because 2PL can cause transactions to wait on each other in a circular pattern, databases run a background deadlock detector that periodically checks for cycles in a wait‑for graph. When found, it picks one transaction as the “victim,” aborts it, and lets the others proceed.

6.6 Lock granularity — row, page, and table locks

Locks can be taken at different levels of granularity, and the choice involves a direct trade‑off between concurrency and overhead.

• Row‑level locks — lock only the specific row being modified. Maximises concurrency (other transactions can freely touch other rows) but requires more bookkeeping, since the database might need to track thousands of individual locks at once.
• Page‑level locks — lock an entire disk page (which may contain several rows). Fewer locks to track, but two unrelated transactions modifying different rows that happen to live on the same page will block each other unnecessarily.
• Table‑level locks — lock the entire table. Cheapest to manage, but effectively serialises all writers — acceptable only for small, rarely‑written tables or bulk administrative operations like schema changes.

Most modern OLTP (Online Transaction Processing) databases default to row‑level locking for regular DML operations, reserving table‑level locks for schema changes like ALTER TABLE.

6.7 Isolation as a data structure problem

Under the hood, MVCC relies on some elegant data structures. Each row typically carries hidden metadata: a creation transaction ID and, if deleted or updated, a deletion/expiry transaction ID. When a transaction reads a row, the engine walks a version chain — essentially a linked list of row versions — and picks the newest version that was already committed before the reading transaction began. Old, no‑longer‑visible versions are eventually reclaimed by a background garbage‑collection process (PostgreSQL’s VACUUM, or InnoDB’s purge thread), which is itself a classic concurrent data structure problem: safely removing entries that no active transaction can possibly still need.

Every ACID transaction moves through a well‑defined set of states. Understanding this flow helps you reason about what your application code is actually doing under the hood.

7.1 Java example: a real ACID transaction with JDBC

The most direct way to feel ACID in your hands is to write it out yourself. Here’s a classic bank transfer using plain JDBC — every line matters.

public void transferMoney(Connection conn, int fromAccountId, int toAccountId, BigDecimal amount) throws SQLException {
    boolean originalAutoCommit = conn.getAutoCommit();
    try {
        conn.setAutoCommit(false); // Start transaction (turn off auto-commit)

        String debit = "UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?";
        try (PreparedStatement ps = conn.prepareStatement(debit)) {
            ps.setBigDecimal(1, amount);
            ps.setInt(2, fromAccountId);
            ps.setBigDecimal(3, amount);
            int rows = ps.executeUpdate();
            if (rows == 0) {
                throw new SQLException("Insufficient funds or account not found");
            }
        }

        String credit = "UPDATE accounts SET balance = balance + ? WHERE id = ?";
        try (PreparedStatement ps = conn.prepareStatement(credit)) {
            ps.setBigDecimal(1, amount);
            ps.setInt(2, toAccountId);
            ps.executeUpdate();
        }

        conn.commit(); // Atomicity + Durability guaranteed here
        System.out.println("Transfer successful");

    } catch (SQLException e) {
        conn.rollback(); // Undo everything if anything failed
        System.out.println("Transfer failed, rolled back: " + e.getMessage());
        throw e;
    } finally {
        conn.setAutoCommit(originalAutoCommit);
    }
}

Notice three critical things in this code: setAutoCommit(false) begins an explicit transaction, commit() makes the change permanent and durable, and rollback() in the catch block guarantees atomicity — if the credit statement throws an exception, the debit statement is undone too.

Full isolation (as if every transaction ran one at a time, alone) is the safest option, but it’s also the slowest, because transactions must wait for each other constantly. So the SQL standard defines four isolation levels, trading correctness for speed.

8.1 The three anomalies

To understand isolation levels, we first need to know the three “anomalies” they protect against.

• Dirty Read — reading a value that another transaction wrote but hasn’t committed yet, and that value might later be rolled back.
• Non‑Repeatable Read — reading the same row twice in one transaction and getting two different values, because another transaction committed a change in between.
• Phantom Read — running the same query twice and getting a different set of rows, because another transaction inserted or deleted matching rows in between.

8.2 The four levels at a glance

8.3 What the popular databases pick by default

Most production systems intentionally avoid Serializable for performance reasons unless correctness absolutely demands it (e.g. financial ledgers, currency conversion, seat allocation for a sold‑out concert).

conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
// Options: TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED,
//          TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE

Nothing in engineering is free. ACID buys correctness at a real, measurable cost — and knowing where each side of the trade‑off lands is what separates a competent operator from a great one.

9.1 Advantages

9.2 Disadvantages

9.3 ACID vs. BASE

Many NoSQL databases (like Cassandra, DynamoDB, and MongoDB in certain configurations) intentionally relax ACID guarantees in favour of a model called BASE: Basically Available, Soft state, Eventually consistent. BASE systems prioritise availability and horizontal scalability over immediate consistency.

ACID guarantees are not free. Every layer of protection adds some cost. Understanding these costs helps you make smart engineering decisions instead of reflexively “removing transactions to go fast.”

10.1 Where the cost comes from

• Lock contention — when many transactions compete for the same rows, throughput drops as transactions queue up waiting for locks.
• fsync latency — forcing WAL data to physical disk on every commit is one of the biggest bottlenecks in write‑heavy systems. SSDs and battery‑backed write caches help, but the cost never fully disappears.
• MVCC bloat — keeping multiple versions of rows means old versions must eventually be cleaned up. PostgreSQL calls this VACUUM. Neglecting it can degrade performance significantly over time.
• Long‑running transactions — a transaction that stays open too long holds locks and prevents cleanup, slowing down the entire system.

10.2 Common scaling strategies

10.3 Understanding the cost of fsync

It’s worth understanding exactly why a single line of code — forcing a write to disk — can dominate database performance. A modern CPU can execute billions of instructions per second, and even a fast NVMe SSD write can take a fraction of a millisecond, but the physical act of guaranteeing that data has actually reached persistent storage (not just an in‑memory disk cache that could be lost on power failure) involves a round‑trip through the operating system’s I/O subsystem that is orders of magnitude slower than in‑memory operations. This is precisely why databases batch multiple transactions’ log records into a single fsync call whenever possible — a technique called group commit. If ten transactions commit within a few milliseconds of each other, the database can often flush all ten log records to disk in a single fsync operation, amortising the fixed cost of the disk flush across many transactions and dramatically increasing throughput without sacrificing durability for any of them.

10.4 Throughput vs. latency

It’s useful to separate two related but distinct performance concerns. Latency is how long a single transaction takes to complete. Throughput is how many transactions the system can process per second overall. Techniques like group commit improve throughput without necessarily improving the latency of any individual transaction. Understanding which one matters more for your use case — a single user waiting for a payment confirmation cares about latency, while a batch nightly settlement job cares about throughput — helps you choose the right optimisation strategy instead of applying a one‑size‑fits‑all fix.

Once your data spans more than one machine — for redundancy or scale — ACID becomes significantly harder to maintain. This is where the CAP theorem, replication strategies, and distributed transactions all show up together.

11.1 CAP theorem in brief

In a distributed system, when a network partition occurs (some nodes can’t talk to others), you must choose between:

• Consistency (C) — every node sees the same data at the same time.
• Availability (A) — every request gets a response, even if it might not be the latest data.

You cannot have both perfectly during a partition — this is the essence of the CAP theorem. ACID databases traditionally lean toward consistency; many NoSQL systems lean toward availability.

11.2 Distributed transactions — Two-Phase Commit (2PC)

When a transaction must span multiple databases or services, a coordinator uses a protocol called Two‑Phase Commit:

1. Prepare phase — the coordinator asks every participant “can you commit this?” Each participant locks resources and replies yes or no.
2. Commit phase — if everyone said yes, the coordinator tells everyone to commit. If anyone said no, everyone is told to abort.

2PC guarantees atomicity across nodes but is a blocking protocol — if the coordinator crashes after “prepare” but before telling nodes to commit, those nodes are stuck holding locks indefinitely. This is why modern distributed databases often use consensus algorithms like Raft or Paxos instead, which tolerate node failures more gracefully by requiring only a majority of nodes to agree, not all of them.

11.3 Replication for durability

To survive a single machine’s disk failure entirely, databases replicate committed data to multiple nodes before or shortly after acknowledging a commit.

• Synchronous replication — waits for at least one replica to confirm before returning success. Safer, slightly slower.
• Asynchronous replication — returns success immediately and replicates in the background. Faster, small risk of data loss on primary failure.

ACID guarantees data correctness, but it does not automatically make a system secure. Security around transactional systems requires its own set of practices.

In production, you need visibility into how well your database is honouring its ACID guarantees under real load. The right metrics turn a black‑box database into a well‑behaved teammate.

13.1 Key metrics to track

13.2 Tooling

Tools commonly used in production include Prometheus + Grafana for metrics dashboards, database‑native tools like PostgreSQL’s pg_stat_activity view, and distributed tracing systems (like OpenTelemetry) to see how a transaction’s latency fits into the broader request lifecycle across microservices.

Modern cloud providers offer managed relational databases that preserve ACID guarantees while adding operational conveniences like automated backups, patching, and failover — letting you rent correctness by the hour.

Real production systems rarely rely on a single database instance handling everything directly. ACID transactions typically sit at the centre of an architecture surrounded by supporting layers.

• Caching (Redis, Memcached) — frequently read data is cached to reduce load on the primary database. Caches are usually not ACID‑compliant, so applications must handle cache invalidation carefully after a committed write to avoid serving stale data.
• Load balancers — distribute application traffic across multiple app servers, but database writes must still funnel to a single primary (or a consensus‑coordinated cluster) to preserve consistency.
• Read replicas — handle read‑heavy traffic, but may lag behind the primary by milliseconds to seconds (replication lag), which is a deliberate, managed trade‑off against strict consistency for scale.

In a monolithic application, a transaction usually touches one database, so a simple BEGIN...COMMIT block is enough. In a microservices architecture, a single business operation may span multiple services, each owning its own database. This is where ACID becomes genuinely difficult.

16.1 The Saga pattern

The most widely used solution is the Saga pattern: break a distributed operation into a sequence of local transactions, each with a corresponding compensating transaction that undoes its effect if a later step fails.

Sagas give up strict atomicity across services in exchange for scalability and service independence — this is a deliberate, well‑understood trade‑off, not a shortcut. Each individual service still uses full ACID transactions internally; it’s only the cross‑service coordination that becomes “eventually consistent.”

16.2 Idempotency in APIs

Because network calls between microservices can fail and be retried, API endpoints that trigger transactions should be idempotent — calling them multiple times with the same input should produce the same result as calling them once. This is usually implemented with a unique idempotency key sent by the client and checked against a database record before processing.

A handful of small, reusable transactional arrangements show up in nearly every serious system — and a handful of tempting shortcuts turn out to be traps you only learn about the hard way.

17.1 Good patterns

17.2 Anti-patterns to avoid

A short, opinionated checklist that catches the failure modes teams see most often in real production systems using ACID databases.

18.1 Best practices

1. 1. Keep transactions as short as possible

   Do validation and preparation before opening the transaction, not inside it.

2. 2. Always use parameterised queries

   Prevents SQL injection and enables query plan caching by the database.

3. 3. Choose the lowest isolation level that still satisfies your correctness requirements

   Don’t default to Serializable everywhere — you’ll pay for it in throughput.

4. 4. Handle rollback explicitly in a finally or catch block

   Never assume a connection will clean itself up on the way out.

5. 5. Use connection pooling in production

   HikariCP for Java, PgBouncer for PostgreSQL — opening a new connection per request wastes both time and memory.

6. 6. Design a consistent lock acquisition order across your codebase

   For example, always lock accounts in ascending ID order — this eliminates a huge class of deadlocks.

7. 7. Monitor rollback rates and lock wait times as first-class production metrics

   Not an afterthought. Set alerts on them.

18.2 Common mistakes

18.3 A practical checklist before you ship

Before deploying code that opens a database transaction, it helps to run through a short mental checklist: Is the transaction as short as possible? Have I chosen an appropriate isolation level rather than defaulting blindly? Is rollback handled in every failure path, including unexpected exceptions? Are all queries parameterised? Have I considered what happens if two instances of this exact code run at the same moment? And finally — have I actually tested the failure path, not just the happy path, in a staging environment that resembles production load? Teams that make this checklist a habit, rather than a one‑time review, consistently ship far fewer data‑integrity incidents than teams that treat transactional correctness as an afterthought.

Some of the largest computing platforms in the world run on ACID databases, and how they use them tells you a lot about which trade‑offs really matter at scale.

Payroll and accounting systems depend on ACID at an almost philosophical level — the entire discipline of double‑entry bookkeeping, which dates back centuries before computers existed, is essentially a manual form of atomicity and consistency: every recorded transaction must have matching debit and credit entries, or the books don’t balance. When this practice was digitised, ACID databases were a natural fit because they enforce, in software, exactly the same discipline accountants had already been enforcing on paper.

Across all of these industries, the common thread is the same: whenever incorrect or lost data has a real cost — financial, legal, or human — ACID‑compliant databases remain the default, trusted foundation, even as the surrounding architecture (microservices, caching, cloud infrastructure) has grown dramatically more complex over the last two decades.

Short answers to the questions engineers ask most often about ACID.

Everything above, distilled — the parts worth remembering after you close this tab.

• ACID stands for Atomicity, Consistency, Isolation, and Durability — four guarantees that make database transactions reliable.
• Atomicity ensures all‑or‑nothing execution, implemented through undo logs.
• Consistency ensures every transaction respects the database’s rules and constraints.
• Isolation ensures concurrent transactions don’t corrupt each other’s work, implemented via locking (2PL) or multi‑versioning (MVCC), with four standard isolation levels trading strictness for speed.
• Durability ensures committed data survives crashes, implemented through Write‑Ahead Logging (WAL) and fsync.
• ACID trades some raw performance and horizontal scalability for correctness — a trade‑off that is absolutely worth it for banking, payments, inventory, and any domain where wrong data is unacceptable.
• In distributed and microservices architectures, strict ACID across services is replaced by patterns like Saga, Outbox, and consensus protocols like Raft — extending the spirit of ACID into a world where a single database transaction isn’t possible.
• Keep transactions short. Use parameterised queries. Choose the lowest isolation level that still satisfies correctness. Handle rollback explicitly. Monitor rollback rate.
• ACID databases still sit at the heart of virtually every serious system in banking, e‑commerce, healthcare, and ticketing — even as caches, load balancers, and read replicas surround them.