为何Confluent Schema Registry将默认兼容性类型设置为BACKWARD？

首先要明确BACKWARD兼容性的官方定义：所有使用旧版Schema写入的消息，都可以被使用新版Schema的消费者正常解析。Confluent将其设为默认值，核心是适配绝大多数数据处理场景的共性需求，原因主要有以下几点：

• 匹配最普遍的Schema演化流程
  常规业务迭代中，Schema调整最常见的需求是新增可选字段、废弃冗余字段，这类调整的标准流程是先升级消费者适配新Schema，再推生产者用新Schema写入数据。这种流程下不会出现旧消费者读到新Schema数据的问题，BACKWARD兼容性刚好能约束这类演化的合法性，避免非法Schema变更上线。
• 适配历史数据消费的核心需求
  绝大多数Kafka业务场景都存在历史数据回溯需求：比如流任务故障后重放历史消息、离线分析任务拉取全量周期数据做报表、数据审计回溯过往记录等。BACKWARD兼容的Schema体系下，消费者只需要维护最新一版Schema，就可以正常解析从集群最早到最新的所有消息，不需要做历史数据迁移，也不需要在消费逻辑中适配多版本Schema，整体维护成本远低于多端同步更新的成本。
• 对齐Confluent生态的默认行为
  Confluent官方生态的流处理组件（Kafka Streams、ksqlDB）、数据导出组件（Kafka Connect JDBC/对象存储Sink等）默认都会拉取主题最新版本的Schema处理数据，BACKWARD兼容性刚好和这类默认设计匹配，用户不需要做额外兼容性配置就能直接使用全生态组件，降低上手门槛。

你提到的消费者数量远多于生产者、升级消费者成本更高的场景确实存在，这类场景下你可以手动将兼容性调整为FORWARD（使用旧Schema的消费者可以读取新Schema写入的数据）或者FULL兼容性即可。默认值只是适配最通用的场景，并非强制要求所有业务都使用。

内容的提问来源于stack exchange，提问作者Zhenkai