Maintaining Wire Compatibility

In a production software engineering environment, often times one needs to add fields to a proto (protobuf); which is a lightweight message payload format. What is often easy to overlook is that the proto may be in use by a number of downstream customers. Services also may not be fetching the latest version for that proto and therefore may not have access to the most up-to-date format.

In this type of situation there are a number of ways to handle the addition of a new field(s):

• Communicate with downstream customers to update to the latest version of the proto for all of their services. This is generally a cumbersome approach depending on how many customers use the proto.
• Create a new proto that is a copy of the existing one but includes the new field(s) and gradually migrate downstream customers to use the new format.
• Version the proto and enforce strict versioning constraints.

Essentially, the goal of due-dilligence here is to avoid a situation where there is a wire incompatibility. We do not want a downstream service to break because they are calling an endpoint without a newly required parameter. Wire incompatibility is quite a commonplace issue and as an engineer one needs to be careful when rolling out new features to ensure that they are also backwards compatible.

Related Readings:

• Changing Interfaces in a Backward Compatible Manner