Events outlive code
Stored events are read for years by code that keeps changing. So event schemas must evolve while old and new versions coexist. The goal is compatibility so a change never breaks readers or writers running an older version.
Kinds of compatibility
- Backward compatible means new consumers can read old events. Adding an optional field is usually fine.
- Forward compatible means old consumers can read new events, often by ignoring unknown fields.
- Full compatibility satisfies both, which is what long lived event streams need.
Safe and unsafe changes
- Safe. Add an optional field with a default, or widen a value range.
- Unsafe. Rename or remove a field, or change its type, because old readers break.
Practical rules
- Use a schema registry to check compatibility before publishing.
- Never reinterpret the meaning of an existing field.
- When a breaking change is truly needed, introduce a new event version rather than mutating the old one.
Key idea
Evolve event schemas with additive backward and forward compatible changes so old and new code can read the same streams safely.