As the author of a shared Go client package, when do you expose a setting as a Config field rather than an Option?

## Frame the decision correctly The wrong frame is "how many optional parameters do I have". Counting parameters leads to a rule of thumb ("more than four, use options") that produces packages where a deployment timeout and a test clock live in the same mechanism for no reason. The right frame is: **what kind of thing is this setting, who supplies it, and what do they need to do with it afterwards?** That question has an answer per setting, and the answer decides the mechanism. ## What a Config struct gives that options cannot **It is data, so tools can act on it.** A struct with exported fields can be unmarshalled from a deployment file, populated from environment variables, printed at start-up so an operator can confirm what the process actually loaded, diffed between two environments to explain why staging behaves differently, and round-tripped in a test fixture. An `[]Option` is a list of opaque function values: you cannot print it, compare it, serialise it, or ask it what it is going to set. **It validates as a whole.** With a struct, the constructor holds every value at once and can check relationships — that the backoff window fits inside the deadline it retries within, that a keep-alive is shorter than the peer's idle timeout. Per-option checks see one field each. **It reads as a unit in review.** A reviewer looking at a filled-in struct literal sees the whole configuration on one screen. A call with nine options is nine expressions to check individually. ## What options give that a Config struct cannot **Opacity.** A `Config` field is exported by construction: callers can read it, write it, and — if you keep a reference rather than copying — mutate it after the client is running. Options hand the value into unexported fields, so the package retains control of the value's lifetime and of what is even settable. **A natural home for behaviour.** A custom dialer function, an alternative clock, an `io.Writer` for diagnostics, an interceptor to append — these are code. Putting a `func` field in a struct that also gets unmarshalled from a configuration file mixes two populations of value that arrive from different places and are reviewed by different people. **Composability at the call site.** Options can be assembled into named bundles a team applies together, and a caller can pass a `[]Option` built at run time from a feature check. ## The organisational weight, which is the real reason this is a lead's call Both mechanisms grow the exported surface, but they grow it differently, and that difference is what makes it a decision somebody owns: - An **exported Config field** fixes a name and a type publicly and grants write access. Once other teams' code reads and writes `cfg.Timeout`, its type is effectively frozen, and any semantic change is a change to somebody else's compiled code. - An **exported option helper** fixes a name and a signature but keeps the underlying state private, so the package can change how it stores and interprets the value. This is why the review posture differs. I want a second opinion before adding a `Config` field, because it is public writable state; I am more relaxed about an option, because the blast radius is the helper's signature. Neither is free — a package accumulating options nobody uses is its own kind of debt — but they are not the same kind of commitment, and a team should know which one it is granting. There is a second organisational fact: **who fills it in.** If the value is going to end up in a deployment manifest maintained by whoever is on call, it must be a struct field, because that is the shape the file has. If it is going to be set by the one team that needs a fake clock in tests, an option keeps it out of the operators' surface entirely. Deciding by audience gets this right more often than deciding by taste. ## The hybrid, and its one rule Large clients commonly land on `New(cfg Config, opts ...Option)`: the deployment surface in the struct, behavioural hooks as options. It works, and it is honest about the two populations. It has one rule, and skipping it is the failure mode: **document the boundary and hold it**. Write in the package doc what belongs in `Config` and what belongs in an `Option`, and enforce it in review. A package where the timeout is a field, the keep-alive is an option and nobody remembers why is worse than either pure design, because every importing team now has to check the godoc for each setting before they can write a line. ## What I would say in the interview I would give the criterion — data supplied by operators and validated as a set goes in the struct; behaviour and rarely-used tuning goes in options — then name the cost I am accepting on each side, then say who signs off. The point an interviewer is listening for is that this is a surface other people compile against and I cannot quietly retract, so the decision is made deliberately, written down, and applied consistently across the package family rather than per pull request.