No compatibility is a schema policy in which consumers must stay synchronized with producers and cannot rely on reading data across schema versions. Producers may add or remove fields freely, but consumers can struggle with historical data and unsynchronized deployments. section 13.1.2
Renaming product fields
In a supermarket product schema, renaming fields breaks compatibility in both directions: a consumer expecting the previous version cannot read the new data, while a consumer expecting the new version cannot handle old data. The policy fits a producer and consumer managed by one team when Kafka data is not retained for long. section 13.1.2
Figure 13.2 We consider schema compatibility from the consumer’s perspective and which schema versions they can understand. If we can’t or don’t want to guarantee any compatibility, a consumer can only understand their own schema version. A backward-compatible consumer can read historical data but can’t handle newer data. A forward-compatible consumer can read new data, but not historical data. The optimum is a consumer that can read both historical and new data, which is fully compatible in both directions.
Compare which schema versions consumers can understand when no compatibility is guaranteed. section 13.1.2
