Projection

A projection is a fold: for each event or change, apply it to the read model. Simple in outline and demanding in the details.

Idempotency is mandatory, because delivery is at-least-once and a projection will see the same event twice. Track the last processed position, or make the write conditional on a version.

Ordering matters within an entity and usually not across entities, so the partition key of the source stream determines whether the projection is correct — a topic keyed by something other than the entity will deliver two of that entity's events concurrently.

Out-of-order and late events must be handled explicitly. A projection that blindly applies the latest event it receives will regress state when an older one arrives after a retry.

Rebuild must be possible and must be practised. A projection whose rebuild has never been run is a projection whose rebuild does not work — and rebuild is the fix for every projection bug, so it is the capability that matters most.

Lag must be measured, in both position and time, and alerted on. A stalled projection is invisible otherwise: reads succeed, data is wrong, nothing errors.