What is one sign a goroutine may leak?

It has no path that observes cancellation or closed input.

A teammate wants to hide database/sql inside a convenient helper. What should you check first?

Whether the helper makes ownership, inputs, failures, and tests easier to review.

Whether it reduces the number of files regardless of behavior.

Whether it removes the need for the lesson checklist.

Whether it can skip the production signals for this course.

Which artifact best proves this Go Services lesson is ready for review?

A repeatable check tied to migration and HTTP handler tests.

A note that says the happy path was manually clicked once.

A screenshot with no command, test, or failure-mode context.

A broad refactor that avoids the specific lesson outcome.

Intermediate storage and workers: a teammate says the happy path works, but "Storage contract" is still implicit. What should you ask for before merging?

A small contract, test, or review artifact that proves storage contract under a realistic failure case.

Skip compiler, OpenAPI, SQL, or host evidence until the capstone.

Hide the decision inside framework defaults so reviewers have less to read.

Treat production behavior as separate from the lesson implementation.

A reviewer has five minutes to evaluate this intermediate Go Services slice. Which evidence is strongest?

A focused artifact for release command log plus a repeatable test, log, OpenAPI diff, or deployment check.

A passing build with no note about contracts, query shape, or operations.

A screenshot of Swagger without checking response or failure cases.

A broad rewrite that does not map to the stage milestone.

Learn / Go Service Engineering

Storage, Workers, and Release

Persist data, run bounded background work, and ship a small service binary with repeatable checks.

Course: Go Service Engineering. Level: Intermediate. Topic: Reliable services.

Stage: intermediate - Intermediate storage and workers - Storage, workers, and release evidence. Connect database access, background work, and release commands into one reviewable service path.

Outcomes

Use repository interfaces over SQL code.
Stop worker pools cleanly.
Run tests, race checks, and container builds.

Concepts

database/sql
migration
worker pool
race detector

Concept flow

Show how storage, workers, and release evidence moves from trigger to implementation outcome in Go Services.

Handler
Repository
Database
Job queue
Worker pool

Session flow

Model database/sql (concept, 12 min) — Name the decisions behind database/sql before writing code.
- Use repository interfaces over SQL code.
- Explain where database/sql belongs in ticket processing platform.
Build the vertical slice (walkthrough, 21 min) — Implement the smallest useful slice in internal/store/tickets.go.
- Stop worker pools cleanly.
- Connect migration to a working example.
Verify and harden (exercise, 14 min) — Run go test with the race detector on worker code.
- Run tests, race checks, and container builds.
- Record one risk or follow-up before moving on.

Code example

Go in internal/store/tickets.go.

package store
      
      import (
      	"context"
      	"database/sql"
      )
      
      type Store struct {
      	db *sql.DB
      }
      
      type Ticket struct {
      	ID     string
      	Title  string
      	Status string
      }
      
      func (s Store) CreateTicket(ctx context.Context, ticket Ticket) error {
      	_, err := s.db.ExecContext(ctx, `
      		insert into tickets (id, title, status)
      		values ($1, $2, $3)
      	`, ticket.ID, ticket.Title, ticket.Status)
      	return err
      }

Walkthrough examples

Storage, Workers, and Release in a ticket processing platform — A team is extending a small Go service plus worker and needs this lesson's pattern to be clear enough for review, testing, and future maintenance.
- File: internal/store/tickets.go
- File: tests/storage-workers-and-release.spec
- File: docs/go-services/storage-workers-and-release.md
- Start from the provided Go snippet and make the intent visible in names and boundaries.
- Apply the checklist item "Pass context to SQL" before adding extra behavior.
- Write down how the implementation changes when migration fails or becomes slow.

Practice

Add one migration.
Write a repository test.
Run go test with the race detector on worker code.

Checklist

Pass context to SQL
Keep transactions short
Bound worker queues
Document build and run commands

Quiz prompts

What is one sign a goroutine may leak? — Long-running goroutines need a clear shutdown signal so deploys and tests can finish cleanly.
A teammate wants to hide database/sql inside a convenient helper. What should you check first? — Place database/sql at the boundary that keeps ticket processing platform behavior explicit, testable, and reviewable.
Which artifact best proves this Go Services lesson is ready for review? — Production-ready learning needs evidence: a test, trace, command, screenshot, or log that catches the risk again.
Intermediate storage and workers: a teammate says the happy path works, but "Storage contract" is still implicit. What should you ask for before merging? — Storage contract belongs in the intermediate stage only when the decision is visible, testable, and tied to a realistic failure mode.
A reviewer has five minutes to evaluate this intermediate Go Services slice. Which evidence is strongest? — Ship an intermediate worker-backed Go feature with storage transaction proof, bounded queue behavior, and release command evidence.

Flashcards

Intermediate storage and workers: what decision does "Storage contract" force you to make? Make query ownership, transaction scope, and returned DTOs visible at the repository edge. Evidence prompt: Wrap one write in a transaction and document the rollback behavior.
Intermediate storage and workers: what decision does "Worker backpressure" force you to make? Use queues, channel bounds, and retry rules that fail predictably under load. Evidence prompt: Add one bounded queue or retry policy and capture what happens when it fills.
Intermediate storage and workers: what decision does "Release command log" force you to make? Keep build, test, migrate, and run commands repeatable for a teammate. Evidence prompt: Save the exact command log that proves the service is ready to release.
In Go Services, what should you remember about database/sql? database/sql matters here because it supports "Use repository interfaces over SQL code.".
In Go Services, what should you remember about migration? migration matters here because it supports "Stop worker pools cleanly.".
In Go Services, what should you remember about worker pool? worker pool matters here because it supports "Run tests, race checks, and container builds.".
In Go Services, what should you remember about race detector? race detector matters here because it supports "Use repository interfaces over SQL code.".

Labs

Ship a storage, workers, and release slice — Extend a small Go service plus worker with a small but reviewable feature that proves the lesson's architecture in code.
- Ship an intermediate worker-backed Go feature with storage transaction proof, bounded queue behavior, and release command evidence.
- Wrap one write in a transaction and document the rollback behavior.
- Add one bounded queue or retry policy and capture what happens when it fills.
- Save the exact command log that proves the service is ready to release.
- Add one migration.
- Write a repository test.
- The lab demonstrates the intermediate storage and workers outcome without skipping earlier contract evidence.
- Each subtopic has a concrete artifact: Storage contract, Worker backpressure, Release command log.
- The review notes explain how this level changes ownership, verification, or operational risk.

Challenge

Review-ready storage, workers, and release (Stretch) — Ship an intermediate worker-backed Go feature with storage transaction proof, bounded queue behavior, and release command evidence.
- All checklist items are either implemented or documented with a reason.
- The change can be understood from internal/store/tickets.go plus one short note.
- The concept diagram names ownership, failure handling, and verification points.
- A teammate could run the verification steps without asking for hidden context.

Canonical lesson URL