Historical schemas have an operating cost

Start with the recovery promise

A service that promises a full rebuild from retained events needs readers for that history. A service that rebuilds from a recent authoritative snapshot may need a shorter event window. These are different products operationally, even if their live traffic is identical.

State the oldest point from which recovery must work and the acceptable completion time. Without those bounds, historical support can grow indefinitely without anyone deciding whether it remains useful.

Include the cost of producing and validating snapshots if they form part of the alternative. A snapshot that cannot be reconciled or restored is not a cheaper recovery path.

Estimate the work that replay creates

Use retained message count, average processing work and downstream limits to estimate rebuild duration. Then measure a representative slice. Large payloads, old translation paths and historical lookup calls can make replay much slower than current traffic suggests.

An illustrative system with 18 million retained events and a measured safe rate of 500 events per second needs about ten hours for message processing alone. This calculation excludes setup, reconciliation and interruptions. It is a planning example, not a recommended throughput target.

If replay shares resources with live consumers, reserve capacity or isolate it. A fast rebuild that delays current orders may be operationally unacceptable.

Compare translation locations

A consumer can maintain readers for older contracts, or an explicit translation stage can present a current internal representation. The first keeps dependencies local but repeats work across consumers. The second centralises interpretation but creates another component with availability and ownership obligations.

Neither approach can manufacture historical information that was never recorded. An old event missing a delivery method may need an unknown state rather than a confident default. Include such limitations in the estimate of manual recovery work.

Keep original event identity and provenance through translation so the result can be investigated and deduplicated.

Retire history deliberately

Review whether old versions still support a real recovery or reporting requirement. Deleting their definitions while retaining unreadable messages saves little useful complexity.

A retirement proposal should name the replacement recovery source, demonstrate a restore and identify consumers affected by the change. Compare the continuing maintenance cost with that verified alternative. The cheapest option is the one that meets the agreed recovery need with manageable effort, not the one with the fewest schema files.