Lesson 18 · Senior gRPC backend engineering
Proto evolution and compatibility
How to change a protobuf contract without breaking old clients, old servers, or the deploy that happens tomorrow morning.
Your win: explain protobuf compatibility the senior way: what is additive, what is breaking, why field numbers matter more than names, and how rollout safety works when old and new binaries overlap in a real fleet.
The problem: the contract outlives one deploy
A proto change is rarely deployed everywhere at once. One client may already send the new field while another server still runs the old binary. One cron job may restart later. One worker may still have yesterday's image. That is why protobuf evolution is not just syntax. It is compatibility engineering.
If you only read the .proto file in isolation, most changes look innocent. The senior habit is to picture the rollout window: who is still old, who is already new, and what bytes are actually crossing the wire between them?
Safe changes vs dangerous changes
This is the part interviewers often probe: can you separate a tidy-looking change from a compatibility-safe change? They are not the same thing.
- Usually safe: adding a new field with a new number
- Usually safe: reserving removed field numbers and names
- Dangerous: reusing a field number
- Dangerous: changing the meaning of an existing field silently
- Needs thought: changing cardinality, enums, or public HTTP mappings in a way old clients will interpret differently
protoc codegen and buf for lint/breaking checks. That means the day-to-day engineer still has to understand the compatibility model instead of assuming the tooling will save every bad change. The tools help, but the rollout judgment is still yours.
Proto3 guide + update rules
The official protobuf language guide is the right backbone here. Read it with rollout safety in mind.
Check yourself (from memory)
Q1. The real wire identity of a protobuf field is…
Sources. Proto3 guide.