Saga & Distributed Transactions

@Transactional cannot span services, so a Saga commits each step locally and, when Payment fails, runs explicit compensating transactions to undo the earlier committed steps.

Never write to the database and publish to Kafka as two separate steps; write the change and an outbox row in one local transaction, and let a relay publish the outbox with at-least-once delivery.

Write the business change and the event into the same database transaction, then let a separate relay ship the event -- never do two writes to two systems in one method and hope both succeed.

At-least-once means send-then-mark can produce duplicates, so consumers must deduplicate by event id, and a retention job must delete published rows so the outbox never grows without bound.

Do not span two systems with a distributed transaction for the dual write -- commit each system's own local transaction and reach consistency through eventual consistency, idempotent retries, and reconciliation, reserving true atomicity for invariants inside a single store.

2PC trades availability for perfect atomicity by making everyone hold locks until a single coordinator decides, and if that coordinator dies mid-decision they stay locked: which is why microservices prefer Sagas and eventual consistency.

Saga rollback is the orchestrator running idempotent compensating transactions in reverse for every step that already committed, because there is no shared database rollback across services.