In Go, a request struct decoded from JSON carries an empty TenantID three layers deep. How do you keep invalid decoded values out of the rest of the service?

## The failure being diagnosed An internal service has a handler per operation, each one decoding a request struct from the body. One request type has a `TenantID string`. A caller omits the field, the decode succeeds, and the handler passes the struct on. Three layers down, a query is built with an empty tenant filter, or a lookup in a per-tenant map returns the zero value and something dereferences it. The stack trace points at code that is entirely correct; the defect was admitted at the front door and only became visible where the value was finally used. The question an interviewer is really asking is **which layer rejects a bad request**, and the good answer is: exactly one, the outermost, and in a way that makes the inner layers structurally unable to receive one. ## The three candidate layers, and why two of them are wrong - **The layer that finally chokes.** Cheapest to write, worst to operate: the error surfaces far from its cause, the message names an internal concept rather than a request field, and the caller gets a 500 for what was their mistake. It also spreads - every layer starts defensively re-checking, because none can trust its inputs. - **Every layer.** Feels safe, is not. The checks drift apart, the same rule is expressed three ways, and a reader can no longer tell which check is load-bearing. - **The edge.** One check, at the point where untrusted bytes become a Go value, and a type system arrangement that stops an unchecked value from going any further. ## Converting rather than validating The move is to have two types instead of one. The **wire type** mirrors the payload - plain exported fields, json tags, no rules. The **domain type** is what the service actually operates on, and it can only be built by a constructor that enforces the rules: ``` type TenantID string type CreateUser struct { tenant TenantID email string } func NewCreateUser(req createUserRequest) (CreateUser, error) { if req.TenantID == "" { return CreateUser{}, errors.New("tenant_id is required") } if req.Email == "" { return CreateUser{}, errors.New("email is required") } return CreateUser{tenant: TenantID(req.TenantID), email: req.Email}, nil } func (c CreateUser) Tenant() TenantID { return c.tenant } ``` The fields are unexported, so no other package can assemble a populated `CreateUser` without going through `NewCreateUser`. Everything below the handler takes `CreateUser`, never `createUserRequest`. There is no longer a code path along which an empty tenant reaches the query layer, so the query layer does not need a check for it - and the absence of that check is now correct rather than an oversight. ## Named types are half the value `type TenantID string` is a distinct type, not an alias. A function taking a `TenantID` cannot be passed a `string` variable without an explicit conversion, which means a user id and a tenant id cannot be swapped by accident at a call site - a bug that plain `string` parameters make invisible and that no amount of validation catches. (An untyped string *constant* still converts implicitly, which is what makes `TenantID("acme")` and literal test data pleasant to write.) ## The honest limits - **Go always allows the zero value.** `var c CreateUser` and `CreateUser{}` compile anywhere the type is visible, so you cannot make an invalid value unconstructible the way some languages can. What you get is that a *populated* value can only come from the constructor, and a zero value is usually obviously wrong at the point of use. Keep the type in a small package so the constructor is the only interesting thing in it. - **It is more code.** Two structs and a conversion function per operation is real boilerplate. It pays for itself where a request fans out into several layers, where the same field feeds a query, and where the service is called by teams you do not control. For a two-handler internal tool, a `Validate() error` at the edge is a perfectly reasonable stopping point. - **Conversion is where the error message is born.** Return errors that name the wire field - `tenant_id`, not `tenant` - because the client reads the payload, not your struct. Collect them rather than returning the first, so a caller fixing three fields needs one round trip. ## What good sounds like Name the layer, name the mechanism, and be explicit about the guarantee's edges: validation happens once at the boundary; the result is a distinct type with unexported fields and named identifier types; deeper layers accept only that type and therefore stop re-checking; the compiler enforces the shape but not the zero value, and package size is what keeps the remaining gap small.