transaction-consistency

To design transaction boundaries that protect business invariants, define minimal transaction scopes, select appropriate isolation levels to prevent specific anomalies, and ensure remote API calls do not occur while holding database locks.

For distributed consistency without 2PC, apply the Transactional Outbox pattern for local atomicity with event publishing, or use Saga compensation to roll back multi-step writes when invariants span multiple services.

Choosing between optimistic and pessimistic concurrency control depends on your contention profile; define explicit conflict handling and recovery strategies for lost updates or deadlocks when executing concurrent state transitions.

You need explicit isolation levels for multi-step writes like money movement when you must prevent specific anomalies such as dirty reads, non-repeatable reads, phantom reads, or write skew during concurrent updates.

Common failure modes for transactional outbox and saga patterns include stuck Sagas requiring compensation, outbox relay failures, deadlocks, and lost updates, which necessitate explicit testable failure planning.

Remote calls inside database locks should be avoided because external API latency directly expands lock hold times, causing lock contention cascades and severely degrading overall system throughput during concurrent state transitions.