go-service-delivery

To ensure correct context propagation in a Go HTTP service, every exported blocking method must accept `ctx context.Context` and pass it through to DB, HTTP, cache, queue, and goroutine supervisor calls. This prevents cancellation signals from being dropped.

Handling typed errors at Go service boundaries involves using sentinel or typed errors, wrapping them with `%w`, mapping them once at the boundary, and testing with `errors.Is` or `errors.As` rather than relying on string matching. This maintains clear error semantics.

Implementing graceful shutdown and concurrency lifecycle control in Go workers requires capturing goroutine lifetime contracts and adding cancellation or signal drain evidence. You must preserve existing logging and metrics paths while documenting the shutdown sequence.

Writing table-driven tests for Go service failures involves creating scenario-based cases for validation failures, typed error mapping, cancellation, timeouts, idempotency, and persistence errors. You then run focused scoped Go commands and race checks to verify the behavior.

A rollback plan for Go service migrations and repository changes is needed whenever you alter persistence layers or request validation. Documenting reversible migration and rollback paths ensures you can safely return the database or service to its previous state if the deployment fails.

Yes, you can use this approach to review existing handler, service, and repository boundaries in a Go codebase. It evaluates whether responsibilities are clearly separated, context is propagated correctly, and observability instrumentation is preserved through existing logging paths.