# Introduce an outbox without double-publishing existing changes

During migration, old direct publishing and new outbox delivery can overlap. Define which path owns each committed change and make the transition observable.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Map the existing publication paths

Find every place that publishes the event: request handlers, jobs, imports and administrative actions. Identify whether they run before or after the business commit and how retries behave.

Choose a stable event identity strategy for the new path. If the old path cannot provide compatible identifiers, plan how the overlap will avoid creating two indistinguishable business events.

Keep the event's meaning and schema stable where possible while changing delivery mechanics. Combining a contract redesign with the outbox migration makes consumer differences harder to diagnose.

## Deploy durable intent before activating delivery

Add the outbox schema and transactional writes with the publisher initially controlled. Verify that committed business changes create the expected records and rolled-back changes do not.

Decide whether this observation phase can coexist with direct publishing without later replaying the same events. A clear cutover marker or publication ownership field can distinguish records intended for delivery from those recorded only for validation.

Do not simply enable the publisher over every accumulated row if the old path already sent them. That can create a large duplicate wave unless consumers and identifiers deliberately support it.

## Switch ownership at a defined boundary

Choose the deployment or data checkpoint after which the outbox is authoritative for publication. Ensure old application instances and background jobs follow the transition rule during rolling deployment.

Test a transaction in flight at the boundary. It should have one understood publication path, with any duplicate delivery safely handled. Pay attention to retries from requests started before activation.

Monitor committed event counts, unpublished age and consumer outcomes. Reconcile a sample of business changes across the transition rather than relying only on publisher health.

## Plan rollback with pending events intact

If direct publishing must be restored, decide what happens to outbox records already committed but not delivered. Disabling the publisher without handling them can recreate the lost-event gap the migration was meant to remove.

Keep the new event identifiers and consumer duplicate protection during the recovery window. Test rollback with both pending and already published records.

Retire the old publish path only after the new route is reconciled and stable. The migration succeeds when every committed change has a known delivery owner and the overlap cannot silently lose or multiply business effects.

## Sources

- [AWS: transactional outbox pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html)
- [AWS: SQS at-least-once delivery](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues-at-least-once-delivery.html)