What is Ecotone Framework?

Ecotone is the PHP framework for durable workflows, event sourcing, Domain-Driven Design, reliable messaging, and asynchronous communication — one Composer package that adds sagas, orchestrators, aggregates, projections, outbox, retries, and CQRS to Laravel or Symfony through declarative PHP attributes. It runs on the database and broker you already operate; no separate workflow service, no replay-deterministic DSL, no engine-specific event log.

Do I need Temporal or a separate workflow engine to build durable workflows in PHP?

No. Ecotone delivers durable execution on the database and broker you already run. Sagas persist state per identifier, chained workflows survive crashes through the outbox plus async channel, saga timeouts use a #[Delayed] attribute, and Orchestrators (Enterprise) give declarative multi-step workflows. There is no separate cluster to operate, no RoadRunner or ext-grpc requirement, no replay-deterministic DSL — workflows are plain PHP classes with attributes. If you have already adopted Temporal, Ecotone still fits around it for CQRS, projections, distributed messaging, multi-tenant routing, and sagas that aren't full workflows.

Which message brokers does Ecotone work with?

RabbitMQ, Apache Kafka, Amazon SQS, Redis, and the database (DBAL outbox) are first-party — and Ecotone also integrates with Enqueue transports, Symfony Messenger transports, and Laravel Queue channels. Handler code is broker-agnostic: a single #[Asynchronous('channel')] attribute works the same across every transport. CombinedMessageChannel writes the message to the database for the outbox guarantee and dispatches execution on the broker, so outbox draining stays on the database and consumers scale horizontally on RabbitMQ / SQS / Kafka.

Can I use Ecotone with Laravel or Symfony?

Yes. Ecotone ships dedicated packages for both Laravel and Symfony that make integration seamless. After installation, Command, Event, and Query buses are available out of the box in the dependency container — and for any other framework, Ecotone Lite provides a standalone integration via PSR-11.

Do I need to rewrite my application to use Ecotone?

No. Ecotone works alongside your existing application — you adopt it incrementally for the parts where messaging, sagas, event sourcing, or distributed messaging make sense, without rewriting what already works. Ecotone sits above Symfony Messenger and Laravel Queues, using them as transports underneath rather than replacing them.

Why pick Ecotone over Spatie laravel-event-sourcing, EventSauce, or Patchlevel for event sourcing?

Ecotone provides a built-in event store on PostgreSQL or MySQL with #[EventSourcingAggregate], #[ProjectionV2] for read models (global, partitioned, or streaming), default-on gap detection so concurrent-transaction events aren't silently skipped, projection emission via EventStreamEmitter with rebuild auto-suppression, and end-to-end PII encryption across the event store, broker payloads, and structured logs. Compared to Spatie laravel-event-sourcing (Laravel-only, single-process rebuild, no gap detection), EventSauce (no subscription engine, shared-envelope dispatch), and Patchlevel event-sourcing (single-cursor per projection, encryption stops at the event-store boundary), Ecotone covers the operational axes that matter for high-volume event-sourced systems.

Does Ecotone support building systems following Domain-Driven Design?

Ecotone's vocabulary is DDD vocabulary: #[Aggregate], Repository abstraction, #[Saga] as process managers, bounded-context isolation via the Distributed Bus, and Domain Events as first-class plain PHP classes. Where each building block is fully decoupled from the framework using declarative configuration. Ecotone is the only framework that makes DDD build blocks easily composable in Message-Driven systems, to not only ensure clear business logic, but to make the system build on top of reliable architecture.

Asynchronous Communication in PHP

Move any handler to async with one attribute. Atomic outbox in one DBAL transaction. Per-handler failure isolation. #[Delayed], #[Priority], #[TimeToLive] consistent across RabbitMQ, Kafka, SQS, Redis, DBAL, Messenger transports, and Laravel Queue channels — handler code is broker-agnostic.

Asynchronous Communication — full guide Install Ecotone

Composer package · Laravel or Symfony · PostgreSQL or MySQL · RabbitMQ, Kafka, SQS, Redis, or DBAL outbox

What Ecotone provides

Capabilities relevant to asynchronous communication

Reliable Messaging on Any Broker

RabbitMQ, Kafka, SQS, Redis, DBAL outbox. Move handlers to async with one attribute. CombinedMessageChannel writes the message in the same DBAL transaction as the business state, then dispatches execution to the broker. Atomic. Transports swap without code changes.

Resilience Defaults

Transactional outbox, DBAL dead-letter queue with replay, retries with exponential backoff, deduplication, OpenTelemetry on every handler — default behaviour, not assembly required.

Per-handler Failure Isolation

A copy of the message is dispatched to every handler. Each retries independently, fails independently — no shared envelope, no sibling re-runs. One failing subscriber doesn't abort the others.

Runs on the Brokers You Already Have

First-party packages for RabbitMQ, Kafka, SQS, Redis, and DBAL. Ecotone fits your existing stack — no new cluster to operate, no migration of your message infrastructure.

Correlation & Causation, Automatic

Correlation IDs and parent-message IDs propagate from command to every emitted event without middleware. Your OpenTelemetry spans stitch themselves end-to-end — no bundle to install, no stamps to remember.

How it compares

PHP alternatives for this category

Each row names what you'd need to add to match Ecotone, and the architectural ceiling that integration cannot fix.

Symfony Messenger alone

Retry is per-transport. No outbox primitive. Single-tenant per app.

Handlers use `#[AsMessageHandler]` and dispatch via `MessageBusInterface`; transports configured by DSN (`MESSENGER_TRANSPORT_DSN`).
**Retry strategy is per-transport, not per-handler** — two handlers on the same message share the retry envelope, and a failing handler's retry re-runs every handler.
Doctrine transport approximates outbox but is not transactional with the business aggregate by default.
Priority is achieved by separate transports, not first-class.
TTL/delay supported on AMQP/SQS transports, not uniformly across backends.
Multi-tenant routing has no first-class API — single-tenant per application.

Laravel Queues / Horizon

Job runner. No command/event/query separation. No outbox. Horizon Redis-only.

Job class implements `Illuminate\Contracts\Queue\ShouldQueue`, uses `Queueable` trait, defines `handle(...)`.
No native command / event / query separation — one job = one handler; fan-out to multiple subscribers is hand-wired.
No outbox primitive.
Multi-broker is a per-dispatch connection choice, not a channel abstraction above transport.
Priority is the ordered `--queue=high,default` worker arg, not first-class.
Delay capped at 15 minutes on SQS. Horizon is Redis-only.

Ecotone

From #[Asynchronous] on day one to multi-broker outbox at scale.

On day one, `#[Asynchronous('channel')]` moves any handler to async — the same handler code runs on RabbitMQ, Apache Kafka, Amazon SQS, Redis, DBAL, Symfony Messenger transports, or Laravel Queue channels.
As volume grows, `CombinedMessageChannel` splits outbox storage from execution: the database holds the outbox (one poller drains it), the broker carries execution (consumers scale horizontally).
Per-handler failure isolation by default — each subscriber gets its own copy of the message, so one failing handler doesn't trigger sibling re-runs on retry.
`#[Delayed]`, `#[Priority]`, `#[TimeToLive]`, and scheduled messages have one consistent attribute model across brokers.
Dynamic channels route per-tenant at runtime via headers without redeploying.
The dispatch you started with composes upward; nothing is replaced as you scale.

Read the Asynchronous Communication guide

Frequently asked questions

Haven’t found what you’re looking for? Contact us

Symfony Messenger and Laravel Queues are mature dispatchers — they ship transports, retry/failure transport, and middleware. They don't ship the architectural primitives that production async messaging needs above the dispatch layer: transactional outbox, per-handler failure isolation (each subscriber gets its own copy of the message), deduplication, multi-tenant routing, or aggregate / saga / event-store / projection support. Ecotone adds those primitives and uses Messenger transports and Laravel Queue channels as the underlying transport when they're already configured — existing investments stay; new architectural capability is added.

"CombinedMessageChannel::create('outbox_sqs', ['database_channel', 'amazon_sqs_channel'])" writes the message into the database in the same DBAL transaction as the business state change, then dispatches actual handler execution onto SQS (or any broker). One outbox poller drains the database; many consumers handle broker-side execution. If the business transaction rolls back, the atomicy of the changes is ensured. The dual-write problem disappears at the primitive level.

When multiple handlers subscribe to the same event, Ecotone delivers a copy of the message to each handler. If one handler fails, only that handler retries — siblings are not affected. In Symfony Messenger's single-envelope model, the first throwing consumer aborts dispatch for siblings, and retry re-runs every consumer on the same envelope. Per-handler isolation eliminates that class of duplicate side effects.

Yes. Handlers use #[Asynchronous('channel-name')] — broker-agnostic. The channel's underlying transport is bound in one #[ServiceContext] configuration method. Swap RedisBackedMessageChannelBuilder for AmqpBackedMessageChannelBuilder or SqsBackedMessageChannelBuilder — handler code unchanged.

Be part of the change with Ecotone

Unleash the power of Messaging in PHP
and push productivity to the higher level

Get started