A transaction gives an atomic boundary for related changes inside a transactional resource. Isolation controls how concurrent transactions interact. Stronger isolation can simplify reasoning, but it can add aborts, retries, blocking, or overhead. Across independently managed services or data stores, one ACID transaction is often unavailable or undesirable, so consistency must be designed explicitly.
Evidence: S7, S16, S34
Practical rules
Keep one business invariant inside one transactional boundary when possible.
Know the database isolation level; do not assume “transaction” means serial execution.
If serialization conflicts are possible, the application must be able to retry the whole transaction safely.
For dual write such as DB + broker, use a reliable pattern such as transactional outbox instead of two unrelated writes.
For multi-service business workflows, decide whether temporary inconsistency is acceptable and how compensation works.
Evidence: S7, S15, S16
Checklist
Evidence: S7, S15, S16, S34
Advanced concepts to recognize
CAP, consensus, leader election, logical clocks, and distributed locks are important when the problem actually requires them. They are not default ingredients for normal application design.
Reliable DB + message publishing
If one business operation must update a database and publish a message, two unrelated writes can leave the system inconsistent. A transactional outbox stores the business update and an outbox record in one transaction; a separate publisher later sends the message. Consumers still need duplicate-safe processing.
Figure 3. Transactional outbox: atomic local write, asynchronous publication, idempotent consumer.
Diagram loads as you approach it.
Evidence: S12, S15