Backward and Forward Guarantees

## What the two words are actually about A **compatibility guarantee** is a statement about one decode. A **reader** running some version of a schema is handed bytes that a **writer** produced under some other version, and the guarantee says whether that decode is defined. Three things must be named before the statement means anything: the reader's version, the writer's version, and which of the two is older. Candidates who mix the two terms up almost always do so because they attach the word to the *change* or to *whoever deployed*, rather than to the reader. The convention is consistent wherever the terms are used: - **Backward compatible** — a reader on the **newer** schema can decode data written under an **older** one. The new code reaches backwards in time. - **Forward compatible** — a reader on the **older** schema can decode data written under a **newer** one. The old code has to cope with data from its future. - **Full compatible** — both of the above hold, for the same pair of versions. A useful discipline: say the sentence out loud with both versions in it. "A version 5 reader decodes version 4 data" is unambiguous even if you have forgotten which label it carries; the label is just shorthand for that sentence. ## The pair, not the schema Compatibility is a **relation over a pair**, not a property of a single artifact. "Version 5 is backward compatible" is an incomplete claim in the same way that "this number is larger" is incomplete. Version 5 may be backward compatible with version 4 and not with version 2; the two statements are independent, because each concerns a different set of bytes arriving at the same decoder. This matters in three concrete ways: 1. A claim that names no second version cannot be checked, so it cannot be relied on. 2. Two changes that are each compatible with their predecessor can compose into a pair that is not — the stronger, history-wide claim is a separate and strictly stronger guarantee. 3. A request type and a response type between the same two services are two different contracts with two different readers, so they carry their own guarantees independently. ## The table to keep in your head | Guarantee | Reader's version | Data's version | What it buys you | |---|---|---|---| | Backward | newer | older | readers may be upgraded ahead of writers | | Forward | older | newer | writers may be upgraded ahead of readers | | Full | either | either | no upgrade ordering constraint at all | Read the middle two columns first and the label falls out. If the reader is newer than the data, you are talking about backward compatibility. If the reader is older than the data, you are talking about forward compatibility. If you cannot say which is newer, the question has not been posed properly yet. ## Why an interviewer asks this The question is not vocabulary for its own sake. During any rolling change there is a window — minutes for a small service, days for a fleet of a few hundred consumers and a handful of producers — in which both versions are live simultaneously. In that window, four writer/reader pairings occur. Two of them are same-version pairings that were already working. The other two are the cross pairings, and **each direction of compatibility covers exactly one of them**. So the direction that holds is the same fact as the deployment order you are allowed to use, stated a different way. An engineer who can move fluently between "this change is backward compatible" and "therefore consumers go first" has done the rollout; one who can only recite the definitions has not. ## Where the guarantee stops These terms are narrower than they sound, and the boundaries are worth stating explicitly: - They are about **decoding**, not meaning. A field silently repurposed to carry a different quantity under the same name decodes cleanly in both directions and still corrupts everything downstream. No compatibility check catches that, because nothing about the bytes changed shape. - They cover one **version pair**, not a history. Extending the claim over every past version is the transitive form, and it does not follow from the per-step checks. - They say nothing about **which concrete edits** satisfy each direction. That is a separate catalogue, and the answer differs between families of encodings. - Ecosystems genuinely differ in how they express the rules — some resolve a reader's schema against the writer's at decode time, others match on field identifiers alone — but the direction being named is the same in all of them, which is why the terms travel. ## The habit that prevents the mix-up When the label slips, rebuild it from scratch in three steps: name the reader's version; name the version the bytes were written under; ask which is older. Reader newer than the data means backward. Reader older than the data means forward. Both required at once means full, and full is the claim you make when nothing lets you control which side moves first.