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.

Microservices in PHP

Send commands and publish events between PHP services through the brokers you already operate. #[Distributed] handlers, Distributed Bus + Service Map for multi-broker topology, MessagePublisher for outbound integration — transport-agnostic, no custom glue per service pair.

Microservice 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 microservices

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.

Endpoint-ID Routing

Rename classes, move handlers, refactor namespaces — messages still route correctly. The endpoint ID is the contract; FQCN is not on the wire.

Multi-tenant Messaging

Tenant-isolated event streams, tenant-routed message channels, priority routing by customer status. Multi-tenancy as a topology property, not a WHERE clause.

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.

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.

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

Transports point at each other. No shared topology. Single-tenant.

Cross-service messaging via configuring transports that point at each other's queues — there is no shared service-topology declaration.
Routing logic spreads across YAML config, middleware classes, and service-tag wiring per service pair.
The receiving side dispatches one envelope through all matching handlers — a failing handler triggers sibling re-runs on retry.
Multi-tenant per service: officially single-tenant per application.
No idempotency contract; no outbox primitive integrated with cross-service publication.

Laravel Queues / Horizon

Queue connections aren't a service topology. Per-pair custom code.

Queue connections are transport endpoints (Redis, SQS, DB, Beanstalkd) — not a topology of which service consumes which routing keys on which broker.
Cross-service routing, idempotency, outbox, and bounded-context isolation become per-service custom code.
Horizon is Redis-only.

Ecotone

Cross-service messaging that inherits every guarantee your in-process messaging already has.

`#[Distributed]` handlers and the Distributed Bus turn any PHP service into a messaging participant on the brokers you already operate.
The Service Map carries the topology — which service consumes which routing keys on which broker — so adding a service is a config change, not code in every caller.
Every primitive that protects in-process messages applies uniformly across service boundaries: per-handler failure isolation, retry policies, DBAL dead-letter, idempotency, OpenTelemetry, automatic correlation/causation.
Multi-broker single-topology is first-class: some services on Kafka, others on RabbitMQ, others on SQS, all coordinated through one Service Map.
Replaces the per-pair retry-and-serialization glue that grows linearly with service count.

Read the Microservices guide

Frequently asked questions

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

Distributed Bus moves commands and events between PHP services through the brokers you already operate (RabbitMQ, Kafka, SQS, Redis) with guaranteed delivery, retry, and dead-letter built in. REST and gRPC are synchronous request/response — when Service B is down, Service A fails too unless you build your own retry, queue, and outbox layer. The Distributed Bus inverts that: messages persist in your broker, services consume at their own pace, and the same retry / DLQ / idempotency / outbox primitives Ecotone provides for in-process messages apply uniformly across service boundaries.

Yes. The Service Map carries the topology — which service consumes which routing keys, on which broker. Some services run on Kafka, others on RabbitMQ, others on SQS — all coordinated through one Service Map. Switching a service's broker is a Service Map change, not a code change in every service that calls it.

Messages persist in the broker until the target consumer is back. The Ecotone retry policy on the consumer side handles transient failures with exponential backoff, the DBAL dead-letter queue holds messages that exhaust retries for inspection and replay, and idempotency (#[Deduplicated]) means a redelivered message after recovery doesn't produce a duplicate side effect.

Not for service-to-service messaging on brokers you already operate. Ecotone's Distributed Bus + Service Map handle the cross-service routing, retry, serialization, and topology decisions that a service mesh would coordinate in a polyglot HTTP-based environment. Service meshes (Istio, Linkerd) and API gateways add value when you're routing HTTP between many language runtimes; for PHP-on-PHP service messaging through your existing brokers, they're extra infrastructure without clear benefit.

Be part of the change with Ecotone

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

Get started