transaction-consistency

What problem does it solve?

It helps you design transaction boundaries that protect named business invariants while avoiding common causes of contention and inconsistency, such as distributed transactions, remote calls inside database locks, and mismatched isolation/concurrency control.

Core Features & Use Cases

• Minimal isolation + explicit anomaly prevention: Selects and justifies the isolation level by naming the specific anomaly (dirty read, non-repeatable read, phantom read, write skew) it prevents.
• Concurrency-safe locking strategy: Uses optimistic or pessimistic concurrency control with defined conflict handling and recovery.
• Cross-service consistency without 2PC: Prefer Transactional Outbox (event + local atomicity) or Saga compensation when invariants span services.
• Correct remote-call placement: Ensures external API calls do not occur while holding database locks, preventing lock contention cascades.
• Testable failure modes: Guides you to plan for deadlocks, lost updates, phantom cases, stuck Sagas, and outbox relay issues.

Quick Start

Use the transaction-consistency capability to produce a complete consistency plan for your change by specifying the named invariants, the relevant data tables, isolation level choice, concurrency control approach, and the Outbox or Saga design for cross-service writes.