Event schema governance

Measure consumers still using a retired event shape

A producer deployment does not finish an event migration. Track who still depends on the old contract and whether historical recovery remains possible.

In this article

Count dependence, not registrations

A registry can show which schemas exist. It does not by itself tell you whether a monthly reporting job, dormant integration or disaster-recovery process still needs one.

Maintain a consumer inventory with an accountable owner, deployed version and supported contract range. Separate evidence observed from live traffic from compatibility declared by the team. Neither alone gives the complete picture.

For a consumer that runs at month end, a quiet week provides no evidence of successful migration. Include its next scheduled run or an equivalent controlled execution in the acceptance plan.

Observe outcomes by contract

Record processing counts, rejected messages and interpretation failures by event type and contract version. Keep labels bounded. Individual event identifiers belong in searchable records rather than unrestricted metric labels.

Measure lag or completion age separately for old and new contracts. A healthy overall average can hide a small backlog that never progresses because every message uses an unsupported field combination.

Also compare meaningful outputs. In an illustrative invoice projection, count invoices processed and reconcile their totals. Parsing all messages while dropping a discount field is not a successful migration.

Define the retirement condition

A useful condition combines deployed consumers, completed scheduled jobs and historical replay evidence. For example, every registered consumer has demonstrated the new format, no unresolved old-format backlog remains, and the recovery path can interpret retained history.

Do not choose an arbitrary observation window without considering consumer schedules and retention. A weekly consumer and an annual reconciliation process need different evidence. An inactive owner is an unresolved dependency, not automatic permission to remove support.

Keep the conditions readable enough for release review. A dashboard with many green counters is less useful than a short list showing which remaining consumer blocks retirement and why.

Watch after the final switch

Continue monitoring unsupported-version and missing-field failures after the producer stops emitting the old shape. Delayed messages, restored backups and manual replays can reintroduce it.

Retiring live production of a schema and deleting the ability to read it are separate decisions. Document both dates and the recovery consequence of each. The migration is complete when normal operation and the agreed recovery path work, not when the last producer container has restarted.

Primary sources

Confluent: schema evolution and compatibility

References checked 11 September 2026.