advanced

Backward compatibility

Protect independent deployment by keeping old consumers working while producers and consumers roll out at different times.

Producers may deploy before consumers and vice versa. Backward compatible changes let old consumers read new messages (ignore unknown fields) and new consumers read old messages (defaults for missing fields). Forward compatibility is the mirror concern for producers.

On interviews: evaluate whether renaming a JSON field breaks compatibility; use optional fields and schema evolution rules.

Common pitfalls: strict deserialization that fails on unknown fields; enum value removal; tightening validation on the server before clients update.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

Ignore unknown fields on read; optional new fields on write.
Never reuse field numbers or semantic meaning.
Test old producer with new consumer and reverse.
Coordinate enum and status value additions.