Transaction

/trænˈzækʃən/

noun — "atomic unit of work in computing."

Transaction is a sequence of operations performed as a single, indivisible unit in computing or database systems. A transaction either completes entirely or has no effect at all, ensuring system consistency. It encapsulates multiple read, write, or update actions that must succeed together, maintaining data integrity even under concurrent access or system failures.

Technically, transactions are defined by the ACID properties: Atomicity, Consistency, Isolation, and Durability. Atomicity ensures all operations within the transaction are applied fully or not at all. Consistency guarantees that the system remains in a valid state after the transaction. Isolation ensures that concurrent transactions do not interfere with each other, and Durability preserves the committed changes permanently. Database management systems implement transactions through mechanisms like write-ahead logs, locks, or multi-version concurrency control (MVCC).

In workflow terms, a typical example is a bank transfer. A transaction debits Account A and credits Account B. Both actions must succeed together; otherwise, the transaction is rolled back, leaving both accounts unchanged. Similarly, in e-commerce, an order placement may update inventory, process payment, and send a confirmation email—all encapsulated within a single transaction to ensure consistency.

Transactions are also used in distributed systems. Distributed transactions coordinate multiple nodes or services to maintain consistency across a network, often using protocols like two-phase commit or consensus algorithms to guarantee ACID properties across disparate systems.

Conceptually, a transaction is like a sealed envelope containing multiple instructions: it either delivers everything inside or nothing at all, ensuring no partial execution can corrupt the system.

See ACID, Atomicity, Consistency, Isolation, Durability.

/dʊˈrəbɪlɪti/

noun — "changes survive failures permanently."

Durability is a property of transactions in computing and database systems that guarantees once a transaction has been committed, its effects are permanent, even in the event of system crashes, power failures, or hardware malfunctions. This ensures that committed data is never lost and can be reliably recovered, maintaining the integrity of the system over time.

Technically, durability is one of the four ACID properties (Atomicity, Consistency, Isolation, Durability). It is typically implemented through mechanisms such as write-ahead logging, transaction journals, persistent storage, or replication. These mechanisms record the intended changes before applying them, allowing recovery procedures to replay or reconstruct committed operations after failures.

In workflow terms, consider a banking transaction that transfers funds from Account A to Account B. Once the transaction commits, the updated balances are durable: even if the database crashes immediately afterward, recovery processes restore the correct final balances. Durable systems often rely on persistent media like disk drives, SSDs, or distributed replication to ensure long-term reliability.

Durability also extends to distributed systems and cloud storage, where replicated copies across multiple nodes guarantee data survives localized failures. Recovery protocols and consensus algorithms, such as Raft or Paxos, are commonly used to enforce durability in fault-tolerant systems.

Conceptually, durability acts like engraving in stone: once a transaction is recorded and committed, its effects cannot be erased, ensuring consistency and trustworthiness over time.

See ACID, Atomicity, Isolation.

/ˌaɪ.səˈleɪ.ʃən/

noun — "operations shielded from external interference."

Isolation is a property of transactions in computing and database systems that ensures concurrent transactions execute independently without undesired interaction. Each transaction appears to operate in isolation from others, preventing phenomena such as dirty reads, non-repeatable reads, and phantom reads. This property preserves data consistency and integrity in multi-user or multi-process environments.

Technically, isolation is one of the four ACID properties (Atomicity, Consistency, Isolation, Durability) that define reliable transactions. Database management systems implement isolation through locking mechanisms, multi-version concurrency control (MVCC), or serialization strategies. Different isolation levels—such as Read Uncommitted, Read Committed, Repeatable Read, and Serializable—offer trade-offs between consistency guarantees and performance.

In workflow terms, consider two concurrent bank transactions: one transferring funds from Account A to B, and another calculating interest on Account B. Isolation ensures that each transaction sees a consistent view of Account B. The interest calculation cannot observe partial updates from the transfer, preventing incorrect balances.

At a lower level, isolation also applies to threads or processes manipulating shared memory. Atomic operations, mutexes, and semaphores enforce temporary isolation, preventing race conditions and maintaining predictable behavior.

Conceptually, isolation acts like a private workspace: every transaction or operation executes in its own bubble, invisible to others until it completes, ensuring integrity and consistency across the system.

See ACID, Atomicity, Concurrency.

/əˈtɑː.mɪ.sɪ.ti/

noun — "all-or-nothing execution in operations."

Atomicity is a property of operations in computing and database systems that ensures a sequence of actions within a transaction are treated as a single, indivisible unit. Either all actions in the transaction complete successfully, or none are applied, leaving the system in a consistent state. Atomicity prevents partial updates that could lead to data corruption, inconsistencies, or unpredictable behavior.

Technically, atomicity is one of the four ACID properties (Atomicity, Consistency, Isolation, Durability) used to define reliable transactions in database management systems. Implementations often rely on mechanisms such as write-ahead logging, transaction journals, or hardware support like CPU instructions for atomic operations. Low-level atomic operations, such as compare-and-swap or test-and-set, are used in concurrent programming to ensure thread-safe manipulation of shared data without intermediate states visible to other threads.

Atomic operations are critical in multi-threaded or distributed environments. For example, when transferring funds between two bank accounts, a transaction debits one account and credits another. Atomicity ensures that either both operations occur, or neither does, even in the presence of failures like system crashes or network interruptions.

In workflow terms, atomicity can be applied to database updates, file system operations, or message processing in pub/sub systems. Developers rely on atomic operations to guarantee consistency when multiple processes interact with shared resources simultaneously.

Conceptually, atomicity acts like a sealed envelope: a transaction either fully delivers its contents or is never opened, leaving the system state unaltered if any part fails.

See ACID, Transaction, Concurrency.

/ˈeɪ-sɪd/

n. “Guaranteeing your data behaves — no surprises allowed.”

ACID is an acronym describing the foundational properties of reliable database transactions: Atomicity, Consistency, Isolation, and Durability. These principles ensure that when data is read, written, or updated, it behaves predictably — even under crashes, concurrent access, or network issues.

Atomicity guarantees that each transaction is “all or nothing.” If any part of a transaction fails, the entire operation is rolled back, leaving the database in its prior state. Think of transferring money: either the funds leave one account and arrive in the other, or nothing changes.

Consistency ensures that transactions move the database from one valid state to another, obeying all rules, constraints, and integrity checks. For example, foreign key relationships or unique constraints are maintained automatically.

Isolation addresses the problems of concurrent transactions. Each transaction behaves as if it were running alone, even when multiple operations occur simultaneously. This prevents “dirty reads,” lost updates, or other anomalies that could corrupt data.

Durability promises that once a transaction commits, its effects are permanent. Even a sudden system crash or power failure cannot undo committed changes, thanks to mechanisms like write-ahead logs or transaction journals.

ACID principles are critical in relational databases such as SQLServer, PostgreSQL, and MySQL. They form the backbone for applications where data integrity is non-negotiable: banking, e-commerce, enterprise resource planning, and any system where failed or inconsistent writes could be catastrophic.

Beyond traditional relational databases, ACID concepts influence modern distributed systems. Techniques like two-phase commit or consensus protocols extend ACID guarantees across multiple nodes, enabling reliable cloud databases and transaction systems. While NoSQL databases sometimes relax ACID in favor of availability and scalability, understanding ACID remains essential for designing systems that require trust in every operation.

In practice, ACID provides developers and users confidence: you can update, delete, or insert data knowing that the database will never leave you in an inconsistent, partially updated, or corrupted state. It’s the reason that when you check your bank account after transferring money, it always matches expectations.