Event Stream Persistence

PHP Event Sourcing Persistence Strategy

Once you decide to store events, you have to decide how — what database table holds them, how aggregate identity and version are constrained at the storage layer, what happens when you rename a class, and how PII fields are encrypted. This section covers those choices.

The pages below are mostly independent — read the one that matches the problem in front of you:

Persistence Strategies

How Ecotone lays out events on disk: simple append-only streams, partitioned streams (one stream per aggregate with version uniqueness), or a single global stream. Pick the one that matches your concurrency and ordering needs.

Event Sourcing Repository

When you already store events somewhere else (EventSauce, Patchlevel, your own table) and want Ecotone to read/write through that storage instead of its built-in event store.

Making Stream immune to changes

You renamed App\Order\Order to App\Sales\Order — now production events still reference the old class. #[NamedEvent], #[Stream], and #[AggregateType] decouple stored event names from PHP class names so refactors don't break stored data.

Snapshoting

Your aggregate has 50,000 events and rehydration takes seconds. Snapshots store a periodic checkpoint so the aggregate loads from snapshot + recent events.

Event Serialization and PII Data (GDPR)

Your event store contains user emails. The user requests deletion under GDPR and your store is append-only. Crypto-shredding via per-subject keys satisfies the requirement without rewriting events.