The Dual-Write Problem (and How to Actually Fix It)

Once you split a monolith into services, your familiar BEGIN/COMMIT stops working. The dual-write problem means you can't atomically update a database and publish an event — one will always fail independently of the other, leaving your systems silently out of sync.

The textbook answer is two-phase commit (2PC), but it blocks on coordinator failure, requires XA support, and tanks availability. The practical answer is the transactional outbox: write the event into an outbox table inside the same DB transaction as your business data, then let a relay publish it to your broker. For multi-service operations, sagas coordinate a sequence of local transactions with explicit compensating actions — but compensation isn't rollback. A refund is a new operation, not an un-charge.

Before reaching for any distributed pattern, ask whether you split too early. Redrawing service boundaries so the transaction stays local is simpler and more reliable than any coordination protocol.