A topic's subject is registered with FORWARD compatibility. A producer team adds a new field with no default and plans to ship the producer first and let 30 consumer teams upgrade over the following month. A reviewer blocks the change saying the compatibility mode already settled the order and the plan is backwards. Who is right?
Show the full answer Hide the answer
The deciding property
A compatibility mode is not a quality setting. It is a statement about which direction of mismatch is tolerated, and its operational translation is a deployment order. Confluent's own compatibility table carries an "Upgrade first" column for exactly this reason: BACKWARD and BACKWARD_TRANSITIVE say consumers, FORWARD and FORWARD_TRANSITIVE say producers, FULL says any order.
FORWARD means data written with the new schema is readable by a consumer still using the previous one. A reader deserialising with its own older schema simply does not see the added field. So the producer can ship, and the 30 consumer teams can take a month, because during that month the only direction being exercised is the one FORWARD guarantees.
Note which change is in the stem. A field with no default is accepted under FORWARD and rejected under BACKWARD, since a new-schema reader would have nothing to put in that field when reading older records.
What FORWARD buys and what it costs
It buys the rollout the producer team wants: no coordination with 30 teams before shipping.
It costs replayability. Nothing guarantees that a consumer on the new schema can read the retained history, and that is precisely what a reprocessing run does. The bill arrives months later when someone replays 90 days to fix a calculation and the job dies on the first record older than the change, with no field and no default to fall back on.
| If this changes | Choose | Because |
|---|---|---|
| The log is long-retained and replayed routinely | BACKWARD | new consumers must read old bytes |
| Producers cannot wait for dozens of consumer teams | FORWARD | old consumers must read new bytes |
| A shared ledger topic with both properties | FULL | pay for it by never adding a field without a default |
Why the other options fail
- "FORWARD requires consumers first." This is the BACKWARD rule attached to the wrong name, and it is the single most common registry mistake. Under BACKWARD the new schema must read old data, so the readers move first; under FORWARD the old schema must read new data, so the writers move first.
- "Adding a field is safe in both directions." True only for a field with a default, which makes the change FULL-compatible. This field has none, so the backward direction is not guaranteed, and the habit of assuming otherwise is how teams discover their history is unreadable.
- "Switch to BACKWARD first." Switching the mode does not re-validate what is already registered, and under BACKWARD this change would be rejected outright. Changing a subject's mode to get a change through is a decision about every future change on that subject.
When this is the wrong answer
If the consumers are not independently deployed - one team, one repository, one release - the mode is bookkeeping and the order is whatever your deploy pipeline does. Spend the effort on a semantic check instead: the registry sees types, not meanings, and the change that breaks everyone while passing every compatibility check is the one that keeps the field and changes what its values mean.