Semantics on "backwards/forward-compatibility"

Question

As a non-native english speaker, I am always confused on whether there is an arbitrary way to name the following client/server interoperability scenarios:

Scenario A:

clientN+1 - serverN+1
          \
clientN  -- serverN           where N is a concrete arch version

Scenario B:

clientN+1 - serverN+1
          /
clientN  -- serverN           where N is a concrete arch version 

Is one of the scenarios called "backwards-compatibility" and the other "forward-compatibility" in an arbitrary way? Otherwise, if both can be called both ways depending on the reference, then, is client in Scenario A backwards-compatible and server forward-compatible or the other way around?

Answer 1

When something can still connect to a previous version (I assume client - server in A) it is "backwards-compatible" with that previous version. "Forwards compatibility" is not often used in English, but it means the opposite.

Example (A): Client N+1 is backwards-compatible with Server N, Server N is forwards-compatible with Client N+1

Answer 2

You are asking about APIs but I am going to answer in terms of messaging schemas in particular kafka. A subset of the concepts of forward/backwards compatibility in this messaging scenario is directly translatable into the same compatibility concepts for a regular API. When it comes to event driving microservices that exchange messages over a messaging technology such as kafka this sort "messaging API" compatibility problems is the only, and more complex form, of the "microservices API" compatibility problem in your question.

With Kafka there is a schema registry service. You can register a schema that defines the allowable json/avro/protobuf messages for the topic. You can evolve a schema by editing it and it retains a history of versions of the schema. The schema registry has a full API. Its use is optional. You can set a compatibility level for the schemas registered against a topic that are described here. As it is talking about validating/rejecting updating the schema of a topic when attempting to register a new schema based on the following schema compatibility being assigned to the topic. I have edited the text slightly for clarity:

• BACKWARD: consumers using the proposed schema will be able to read data written by producers using the current registered schema
• BACKWARD_TRANSITIVE: consumers using the proposed schema can read data written by producers using all previously registered schemas
• FORWARD: consumers using the latest registered schema can read data written by producers using the proposed schema
• FORWARD_TRANSITIVE: consumers using all previously registered schemas can read data written by producers using the proposed schema
• FULL: the proposed schema is forward and backward compatible with the latest registered schema
• FULL_TRANSITIVE: the proposed schema is forward and backward compatible with all previously registered schemas
• NONE: schema compatibility checks are disabled

The NONE is zero protection. You can register a new schema with no compatibility and you hope that all producers and all consumers are simultaneously updated as being compatible. Older producers will poison the topic. Old consumers will crash trying to read the messages.

The FULL is obvious. No breaking changes are allowed you may add optional fields that might be present. Older producers that do not supply the optional fields do not break older consumers who are not expecting it nor new consumers. New producers do not break old consumers as they will ignore the optional field when reading data out of the message payload.

In the above we see that "direction" counts on whether is it a producer or consumer we are considering which is why we speak about "forward" and "backwards" compatibility.

It is often the case that it is the "data supplier" who is being updated and that it "supplies" the latest version of the data. It is often the case that we don't want to break older "data readers". In the case of kafka it often the case the data producer team who updates the topic schema. Compatibility is whether they will break the multiple consumers. In which case we need that the older schemas are "forwards" compatibility with the newer schemas. Where the real complexity kicks in is when we have older producers sending messages to the same topic concurrently with newer producers sending newer messages to the same topic.

I do not think that being a native English speaker is really an issue here it is a matter of having clear definitions. In the case of simple APIs with a single "supplier" then we we can talk about "forwards compatibility" of the consumer of the API or "backwards compatibility" of the new API to older readers. We naturally talk about updating our APIs in a "backwardly compatible" manner. Yet it is really the "forwards compatibility" of all your existing API consumers that you are trying to maintain. It is a matter of perspective.