I'm excited to launch PHPOutbox today. If you are building event-driven PHP applications, you have likely run into the dreaded "dual-write" problem: your database transaction succeeds, but pushing the subsequent event to your queue fails. The result is lost events and inconsistent data. PHPOutbox solves this by implementing the Transactional Outbox Pattern to guarantee at-least-once event delivery. It allows you to store events in the same database transaction as your business data. A background relay then safely picks them up and publishes them to your message broker. Both succeed, or both fail. Key features we built into it: Framework-Agnostic: Core works with raw PDO, but includes first-party adapters (Facades, Commands, ServiceProviders) for Laravel and Symfony. Concurrency Safe: Supports multiple concurrent relay workers using SELECT FOR UPDATE SKIP LOCKED. Resilient: Includes automatic retries with backoff and a dead-letter queue for exhausted messages. Observability: Built-in PSR-3 logging and relay cycle metrics. I built this to bring a robust, standardized outbox solution to the PHP ecosystem. I'd love to hear your feedback, use cases, or any questions you have about the architecture! Let me know what you think in the comments. 👇

Forum Threads

p/phpoutbox-transactional-outbox-for-php

•

1mo ago

How do you handle reliable event dispatching in PHP? (Introducing PHPOutbox)

Handling events in distributed systems often leads to the "dual write" problem where saving state to the database succeeds, but publishing the corresponding event fails.

To solve this, I built PHPOutbox, a package that implements the Transactional Outbox pattern to guarantee at-least-once event delivery for PHP applications.

View all

PHPOutbox

Guaranteed at-least-once event delivery for PHP

Guaranteed at-least-once event delivery for PHP

Forum Threads

How do you handle reliable event dispatching in PHP? (Introducing PHPOutbox)

Forum Threads

How do you handle reliable event dispatching in PHP? (Introducing PHPOutbox)