Event Versioning
Evolving event schemas without breaking consumers that may read messages written months earlier.
Harder than API versioning, because there is no synchronous caller to negotiate with and events may be replayed from a retained log long after they were written. A breaking change is discovered by a consumer failing on old data, not by an integration test.
The rules mirror API compatibility: add optional fields, never remove or rename, never narrow a type, never change the meaning of an existing field.
When a genuinely breaking change is needed, the options are a new event type published alongside the old for a transition period, or upcasting on read — transforming old events into the current shape as consumers read them, which is the event-sourcing approach and carries a permanent maintenance obligation.
The enforcement that makes it real is a schema registry with a compatibility mode checked in CI, so a breaking change fails the producer's build rather than a consumer's runtime.