For a gRPC/HTTP request that calls another microservice and writes to a database, you've got: * Handler maps the wire format message to an internal entity. Ret

For a gRPC/HTTP request that calls another microservice and writes to a database, you've got: * Handler maps the wire format message to an internal entity. Return a bad-request type error if it fails. * Handler calls controller. Perhaps some specific error conditions get dedicated status codes, the rest get 5XX. * Controller calls gateway. Except in rare cases where the external call is optional, you probably just bubble this to the handler. * Gateway maps internal entity to wire protocol format request. Sometimes this transformation can have errors; bubble these up. * Gateway calls wire protocol client. Wire protocol client may have built-in retries, or gateway may have application-level retries. In any case, if retries are exhausted, bubble this up to the controller. * Gateway maps wire protocol response to internal entity. Depending on the schema, this can often fail to be well-formed, even if the request is "successful." These errors also need reported to the controller. * If everything is successful up to this point, controller calls repository. Bubble errors to handler. * Repository maps internal entity to storage model. Sometimes this transformation is also fallible. * Repository calls storage client. These errors might be retryable but after retries, need bubbling up. * Finally, storage client returns successful value to repository returns to controller returns to handler returns to wire protocol server. This is just a hello-world level microservice. We have thousands of them, with easily a dozen endpoints each and probably 5+ interactions per endpoint on average. And oh yeah, every single one of these error return sites needs a unit test case.