An event schema must change while consumers and retained history both depend on the old version. How is this managed?

The constraint that makes this hard

Events are immutable and retained, so every version of every schema must remain interpretable for as long as the data is retained. Unlike a database schema, which describes current state, an event schema describes records that already exist and cannot be migrated.

Five years in, the consuming code handles versions written by systems nobody remembers — a permanent, compounding obligation.

The management

1. A schema registry enforcing compatibility as a build gate. Registration in CI means an incompatible change fails the producer's build before merge, at the place the change is made. A registry consulted at runtime, or a documented convention, prevents nothing.

2. Full compatibility as the default for a shared stream — both backward and forward — because you cannot control whether producers or consumers upgrade first, and both orders occur.

3. Additive change only, in practice. Add optional fields with defaults. Never remove a field, never change a type, never reuse a field identifier — reusing a field number after removal produces silent data corruption rather than an error, which is the most dangerous available mistake.

4. Deprecation rather than removal. A field marked deprecated, with usage measured, remains readable while new producers stop populating it.

5. A new event type for genuinely breaking changes, with both published during a transition and consumers migrated individually. This is the escape hatch when compatibility cannot be preserved.

6. Version carried in the event, so consumers can branch explicitly rather than inferring.

Why the batch consumer fails at 2 a.m.

Worth noting because it is characteristic. Interactive consumers fail immediately and loudly; batch consumers fail overnight, having skipped a run — and the delay between the change and the visible consequence obscures the causal link.

This is the specific reason enforcement must be at build time, not at runtime discovery.

The governance framing

Once an event has consumers outside the producing team, its schema is a public API. It deserves the same versioning discipline, deprecation process and consumer measurement as any published interface — which organisations routinely fail to apply, because an event does not look like an API.