Staff / expert · Modules and tooling
API evolution and toolchain changes
How do you upgrade a Go service without silently changing its contract?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Review compiler/runtime release notes, module graph changes and API behavior separately. The go directive and toolchain selection affect the effective build environment; transitive dependencies may raise minimum requirements.
Test wire formats, errors, cancellation and zero-value behavior, not just exported signatures. A change can compile and still break callers by wrapping a new error, changing JSON fields or reordering externally visible results.
Roll out with comparable metrics, versioned artifacts and a rollback path that accounts for data/schema compatibility. A binary rollback does not reverse an incompatible migration or emitted event format.
Common trap
Passing go build is necessary evidence, but not a backwards-compatibility proof.
Try it
An upgrade changes persisted JSON from an omitted field to an explicit null. Which tests matter?
Worked solution
Use contract/golden fixtures for old readers and stored records, test round trips and check client expectations. Decide whether the format needs a version or migration before deploying; do not rely only on struct compilation.
Change the constraint
How would you deploy a schema change so both old and new service replicas remain compatible?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.