Symfony Messenger Transports: Building a Transactional Outbox on Top

The dual-write problem, DispatchAfterCurrentBus, and turning Symfony's Doctrine transport into a real transactional outbox with a relay.

venerdì 3 luglio 2026 New tab

1,479 words~7 min read

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework

Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go

My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools

Me: xgabriel.com | GitHub

You save an order. The row commits. Then you dispatch OrderPlaced to RabbitMQ so billing, search indexing, and the welcome email all fire. RabbitMQ was mid-restart for four seconds. The dispatch throws. Your order is in the database and no downstream system will ever hear about it.

Symfony Messenger Transports: Building a Transactional Outbox on Top

Symfony Messenger Transports: Building a Transactional Outbox on Top

Related reading

Migrating Laravel to Symfony Without Rewriting Your Domain

The Unit of Work Boundary in PHP: One Transaction Per Use Case

The Symfony Scheduler Component: Cron in Your App, Not Your Crontab

Hand-Rolled Mappers vs AutoMapper: Keeping the PHP Domain Pure at the Boundary

Eloquent Events vs Domain Events: Why the Framework Hook Isn't Enough

Designing a Transactional Outbox for Reliable Event Delivery in SaaS Platforms

Related reading

Migrating Laravel to Symfony Without Rewriting Your Domain

The Unit of Work Boundary in PHP: One Transaction Per Use Case

The Symfony Scheduler Component: Cron in Your App, Not Your Crontab

Hand-Rolled Mappers vs AutoMapper: Keeping the PHP Domain Pure at the Boundary

Eloquent Events vs Domain Events: Why the Framework Hook Isn't Enough

Designing a Transactional Outbox for Reliable Event Delivery in SaaS Platforms