Catalog
concept#Architecture#Software Engineering#Integration#Reliability

Transactions

Transactions group multiple operations into an atomic unit to ensure consistency and fault tolerance of state changes.

Transactions are atomic units that ensure consistency of state changes in databases and distributed systems.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Relational databases (PostgreSQL, MySQL)Messaging systems (Kafka, RabbitMQ) for saga coordinationTransaction or orchestration libraries

Principles & goals

Define transaction boundaries clearly and explicitlyPlan for error handling and compensationAlign isolation and consistency with business requirements
Build
Domain, Team

Use cases & scenarios

Compromises

  • Deadlocks and lock contention with poor design
  • Faulty compensations can produce inconsistent states
  • Excessive transaction duration increases system load
  • Limit transaction duration and scope
  • Use idempotent operations for retries
  • Instrument locks, latencies and rollbacks for monitoring

I/O & resources

  • Business requirements for data consistency
  • Supporting database or messaging infrastructure
  • Monitoring and observability tools
  • Atomic state changes or consistent end states
  • Transaction and error logs
  • Metrics for throughput, latency and errors

Description

Transactions are atomic units that ensure consistency of state changes in databases and distributed systems. They provide ACID properties—Atomicity, Consistency, Isolation, Durability—or alternative approaches (sagas, idempotent operations) for distributed contexts. Implementation requires coordinated error handling and suitable isolation choices.

✔

  • Ensures consistency and integrity of data changes
  • Enables predictable error handling (rollback/compensation)
  • Improves traceability through explicit boundaries

✖

  • Strong isolation can limit performance and concurrency
  • Distributed transactions increase complexity and latency
  • Not all systems fully support ACID in distributed scenarios

  • Transaction throughput (TPS)

    Number of completed transactions per second; measures system capacity.

  • Transaction latency

    Average time from start to commit/rollback; important for user experience.

  • Rollback rate

    Share of transactions that are rolled back; indicates errors and conflicts.

ACID transaction in a relational DB

A money transfer between accounts as an atomic DB transaction with commit/rollback.

Saga for distributed order

Linked steps (payment, shipping, inventory) are coordinated via local transactions and compensations.

Optimistic concurrency control

Read, modify and conditional write with version checks to avoid locks.

1

Analyze consistency requirements and SLAs

2

Select suitable patterns (ACID, saga, idempotent APIs)

3

Implement with tests, monitoring and compensation logic

⚠️ Technical debt & bottlenecks

  • Legacy systems without transactional guarantees
  • Ad-hoc compensations instead of unified strategies
  • Insufficient tests for error and retry paths
LockingNetwork latencyTransaction coordination
  • Using 2PC over remote, unstable networks without timeouts
  • Excessive lock times due to large transaction batches
  • Ignoring isolation effects in parallel updates
  • Chasing perfect consistency without considering availability
  • Underestimating complexity of distributed error handling
  • Lack of observability leads to hard-to-diagnose rollbacks
Database and transaction conceptsError handling in distributed systemsMonitoring, tuning and deadlock analysis
Consistency requirements of business processesScaling and latency goalsFault tolerance and recovery strategies
  • • Database or platform capabilities (e.g., 2PC support)
  • • Business requirements for latency and throughput
  • • Regulatory requirements for traceability