As we saw in Chapter 1, Building Big with Go, a contract for a service is a definition of various operations that the service provides, with a clear definition of output for a set of expected input. This is also sometimes called the spec (short for specification). The spec might also include non-functional requirements, such as expected budgets for latencies of specific APIs and the expected throughput for which the service guarantees the response times.
The following diagram shows a relative graph of the costs of bugs at various stages of the software life cycle:
As changes are made to the service, it must guarantee that the contract is always honored. Generally, the contracts flux, with an addition in functionality, but they should be backward compatible (ideally). A service...