Catalog
concept#Data#Reliability#Architecture#Integration

ACID

ACID defines four properties (Atomicity, Consistency, Isolation, Durability) for database transactions that ensure data integrity and predictable behavior under failures.

ACID is a foundational principle for transactions in database systems; it groups Atomicity, Consistency, Isolation and Durability to ensure integrity and recoverability.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Advanced

Technical context

Relational databases (e.g., PostgreSQL, Oracle)ORMs and transaction frameworks (e.g., Hibernate, Spring TX)Distributed transaction coordinators (XA, two-phase commit)

Principles & goals

Treat transactions as indivisible operations with clear commit or rollback outcomes.Consistency is enforced via defined integrity constraints and atomic changes.Isolation mitigates concurrency issues using locking or multiversioning strategies.
Build
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Deadlocks and lock contention under high concurrency.
  • Misinterpreting ACID as the sole guarantee for correct business logic.
  • Hidden performance issues from inappropriate isolation settings.
  • Keep transactions short and include only necessary changes.
  • Choose appropriate isolation; do not default to the strongest level.
  • Prepare idempotent operations and compensation logic for distributed cases.

I/O & resources

  • Transaction boundaries (BEGIN/COMMIT/ROLLBACK)
  • Defined integrity constraints
  • Durable storage with crash recovery
  • State changes either fully applied or reverted
  • Durable transaction logs for recovery
  • Definitive transaction metadata and status

Description

ACID is a foundational principle for transactions in database systems; it groups Atomicity, Consistency, Isolation and Durability to ensure integrity and recoverability. It defines expectations for failures, concurrency and persistence, and highlights typical design and performance trade-offs in system architecture.

✔

  • Ensures data integrity even in the presence of system failures.
  • Simplified error handling via clear commit/rollback semantics.
  • Improved auditability through durable transaction logs.

✖

  • Performance overhead from lock management and log writes.
  • Challenges scaling across distributed systems without additional mechanisms.
  • Not always compatible with eventual-consistency architectures.

  • Transactions per second (TPS)

    Measures throughput of successful transactions per time unit.

  • Average transaction latency

    Time between transaction start and commit or rollback.

  • Aborted/failed transactions

    Share or count of transactions that were rolled back.

PostgreSQL: Transactions and WAL

PostgreSQL uses write-ahead logging and supports ACID properties for relational transactions in single-instance deployments.

Banking system with ACID-backed transfers

A core banking system uses atomic transactions to make account transfers consistent and auditable.

E-commerce: Order and inventory transactions

E‑commerce platforms combine ACID transactions for checkout with asynchronous processes for scaling.

1

Identify critical domains requiring strict consistency; define transaction boundaries.

2

Select and configure appropriate isolation levels in the DBMS.

3

Implement logging and durability strategies (WAL, fsync, replication).

4

Monitor lock stats and transaction latencies; optimize long transactions.

5

For distributed scenarios: evaluate two-phase commit vs compensation/idempotency strategies.

6

Document operational and recovery procedures and test cases for failure scenarios.

⚠️ Technical debt & bottlenecks

  • Monolithic transactions couple multiple domains and hinder scaling.
  • Missing compensation paths for failed distributed operations.
  • Insufficient metrics and tracing for transactional latencies.
long-transactionslock-contentiondistributed-coordination
  • Using transactions to control long-running batch analytics.
  • Relying on autocommit semantics for multi-step business processes.
  • Assuming ACID across distributed systems is automatic without coordination.
  • Hidden retries can duplicate side effects.
  • Implicit locks can cause unexpected timeouts under load.
  • Assumptions about durability without verifying storage stack settings.
Database fundamentals and transaction theoryKnowledge of isolation levels and locking mechanismsAbility to analyze failures and plan recovery
Data integrity and compliance requirementsOperational availability and fault tolerancePerformance and scalability requirements
  • • Requirement for durable storage layers (WAL/commit log)
  • • Limited scalability without additional patterns (sharding, CQRS)
  • • Dependence on DBMS support for transaction isolation