Dual Writes Problem

Overview

The dual writes problem appears whenever code does save(entity) followed by publish(event). Each step can fail independently, and there is no transaction coordinating them.

Swapping the order only changes the failure: lose the event, or emit an event for a change that never happened.

It is worth spotting in the wild. Typical shapes include updating a database and then a search index, saving an order and then sending an email, or writing a database row and then invalidating a cache. Each looks harmless in a happy-path test and fails only under crashes, timeouts or deploys, which makes it a persistent source of data drift.

How it works

The fix is to make one write the source of truth and derive the other. With an outbox, the event row commits atomically with the state, and a relay publishes it.

-- broken
db.save(order)        # crash here...
broker.publish(evt)   # ...event lost

-- fixed
BEGIN; INSERT orders ...; INSERT outbox(evt); COMMIT;
relay: read outbox -> publish -> mark sent

The two main cures differ in where capture happens. A transactional outbox captures events in application code inside the same transaction. Change data capture tails the database write-ahead log and requires no application changes, but couples consumers to table structure unless you add an outbox table anyway. Either way, the relay is at-least-once, so downstream handling must tolerate duplicates.

Pitfalls

• Wrapping both calls in try and catch with retries, which cannot survive a process crash.
• Using two-phase commit across heterogeneous systems that do not support it.
• Publishing inside the database transaction, then rolling back.
• Skipping consumer idempotency after adding a relay.

Key takeaways

• Two independent writes cannot be made atomic by careful code.
• Make one write authoritative and derive the rest.
• Use outbox or change data capture.
• Pair with idempotent consumers and reconciliation.