When designing a new wire contract, what do you commit to by declaring a field required rather than optional?
answer
- a promise at the decode boundary
- absence becomes an error, not a state
- every future writer is bound
- no way to say not known yet
- readers must be relaxed before writers
basics
~20 sYou commit every writer, forever, to supplying the field, and every reader to failing the decode when it is missing. Required removes the reader's ability to express unknown, and relaxing it later means updating every reader first.
solid answer
~40 sRequired is a promise made at the decode boundary: a reader that meets a record without the field must treat that as an error, not as a value. Three consequences follow. Every writer that will ever exist must supply the field, including one built years later against a purpose it does not have. The record loses its way of saying *not known yet*, so half-built or imported data has to invent a filler value. And relaxing the field later is not a local edit — every reader has to stop failing on absence before any writer may start omitting it, which is why the decision is usually described as a one-way door. Optional plus an explicit validation rule gets you the same guarantee where you want it, without freezing it into the contract.
go deeper
Know that required means a reader refuses a record lacking the field, while optional means the reader has to cope with it being missing. That difference alone is the junior expectation.
Explain that the check lives at the decode boundary, before any business logic, and that required says nothing about whether the value is meaningful — only that some value was present.
Demonstrate the ordering constraint: every reader has to stop failing on absence before any writer may omit the field, and some readers are archives or consumers you do not deploy.
Own the policy. Keep the contract permissive and the validation strict, and be able to say which handful of fields genuinely earn required across the whole estate, not per team.
## What required actually means Declaring a field required is not a hint about how the field is normally used. It is an instruction to the decode step: when a record arrives without this field, refuse it. The check happens before any business code runs, on bytes from a sender you may not control, with the only available outcome being failure. That is a strong guarantee and it has real value. A reader of a required field never writes a branch for absence, never invents a default, and never carries a nullable through ten layers of code. When the field really is intrinsic to the record — an identifier without which the record means nothing — required is the honest declaration. ## The three things you commit to 1. **Every writer, forever.** Not just today's writers. A backfill job, an importer for legacy data, a test fixture, a service written years later by a team that has never heard of this field — each must supply a value. When one of them does not have a real value, it supplies a fake one, and the contract's guarantee quietly becomes a guarantee that the field is *populated*, not that it is *meaningful*. 2. **A hard failure at the boundary.** Absence becomes an error rather than a state. Sometimes that is exactly right. Sometimes it means a batch of ten thousand records is rejected because one field is missing from one of them, at a point in the pipeline where no human is watching. 3. **No way to say unknown.** A required field cannot represent *we have not found this out yet*. Systems that ingest data from the outside world almost always need that state, and if the contract will not carry it, it reappears as a sentinel — an empty string, a zero, a placeholder date — that every reader must know about and none of them validates. ## Why it is called a one-way door Going from optional to required tightens what senders may do; going from required to optional loosens what readers must accept. The loosening is the awkward direction, because the readers are the ones already deployed and already failing on absence. To relax the field you have to update every reader so that absence is no longer an error, wait until that is true everywhere — including readers you do not own, offline consumers, and anything replaying archived records — and only then let a writer start omitting it. The ordering is forced, the waiting is real, and in a system with independent deployment it can take a long time. Compare that with the cost of getting it wrong in the other direction. A field declared optional that turns out to be intrinsic can be enforced immediately with a validation rule in front of the business logic, which you can deploy on your own schedule and relax again the same afternoon. The asymmetry is the whole argument. | Declaration | Enforced where | Cost of changing your mind | |---|---|---| | Required in the contract | At the decode boundary, by every reader | Every reader must be relaxed before any writer may omit it | | Optional plus a validation rule | In one service, after decoding | Change the rule and redeploy that service | ## The design rule most teams converge on Keep the contract permissive and the validation strict. Declare fields optional unless absence genuinely makes the record meaningless, and express the real business requirement as a rule you own, close to the logic that depends on it. Two practices keep this from becoming an excuse for sloppiness: - State the requirement somewhere machine-checkable, so it is not merely folklore in one service's code. - Fail loudly when it is violated, with a message naming the field, rather than defaulting silently and letting a placeholder value flow onward. And resist the reflex that every field which is always populated today should therefore be required. "Always populated" is an observation about current writers; required is a claim about all future ones. ## The senior signal The answer that lands is the one that names the decode boundary rather than the validation layer, and then explains the ordering constraint — readers first, writers second — that makes the reverse change expensive. A candidate who has lived through it usually mentions the population that cannot be updated on demand: archived records being replayed, or a consumer outside the team's control.
- If required is so costly to reverse, when is it still the right call?When absence makes the record meaningless — a record identifier, or the discriminator that says which shape the rest of the payload has. Without it a reader cannot do anything sensible anyway, so failing at the boundary is more honest than constructing a half-record and failing later with a worse message. The test is whether any reader could proceed usefully without the field.
- What usually happens in practice when a required field has no real value to supply?The writer invents one: an empty string, a zero, a placeholder date, a synthetic identifier. The contract is satisfied and the guarantee is hollow, because readers now receive a value that looks real and is not. This is worse than an honest absence, since absence is at least visible to a reader while a plausible filler is not.
- Does a required field give a reader any guarantee about the value itself?No. It guarantees only that some value was present in the bytes. Range, format, and meaning are all unchecked, and an empty string or a zero satisfies required perfectly well. If the real requirement is a non-empty, well-formed value, that is a validation rule and has to be written as one.
saying these in an interview costs you the question
- Marks a field required because today's writers always populate it
- Thinks a required field guarantees the value is meaningful
- Believes relaxing required is a one-line contract edit
- Assumes a missing required field defaults instead of failing
- Ignores readers outside the team when loosening a field