projection-patterns

Define a Projection class with a name, a list of handled event types, and an apply method that updates your read model tables. A Projector then reads events from the event store in batches, dispatches them to matching handlers, and saves checkpoints after each event.

Create a projection that handles product or document events and calls the Elasticsearch index, update, or delete APIs per event type. Use the event's entity ID as the document ID so updates and deletes target the correct document.

Live projections process events in real time from a subscription for current-state queries. Catchup projections process historical events to rebuild read models. Persistent projections store checkpoints so they can resume from the last processed position after a restart.

Delete the projection's stored checkpoint, optionally clear its read model tables, then rerun the projector from position zero with a larger batch size. This replays all historical events through the projection handlers to reconstruct the read model.

Projections must be idempotent because events can be replayed during rebuilds or redelivered after failures, and applying the same event twice must not corrupt the read model. Use upserts, unique constraints, and version checks to make handlers safe to replay.

Avoid inline projections, which update the read model in the same transaction as the write, when read model updates are slow or target external systems like Elasticsearch. Inline projections add latency to writes and couple availability of the read side to the write path.